Showing results for 
Search instead for 
Did you mean: 

ZF7731 Point to Point Connections gets dropped

Contributor III

i have a Problem with two ZF7731 connected together in a Point-to-Point Installation.

The Wireless Connection sporadically gets dropped. My Root-Bridge still show a Connection to my Non-Root-Bridge. If i try to ping the Non-Root-Bridge or try to a Performance Test with Speedflex i dont get a Connection. If i access the GUI from the Root-Bridge the Connection is listed as "online". In Fact it isn't.
If i reboot the Root-Bridge my Wireless Connection is back online and everything works fine. This Problem occours ones a day on different Times.

The Distance between the Bridges is 75 Meters.
The Line of Sight between them is clean.
Channel Selection is set to "SmartChannel"

I tried so set a static Channel. But this did not solve my Problem.
Any other Ideas or something i could try to solve this.

Thanks and Best Regards

Esteemed Contributor II
Channel 100 is in the UNI-II middle band, subject to DFS/Radar detection. A daily
burst of radar might be a factor. If you can use channels 149-161 in Germany, this
would avoid that possibility.

Otherwise, to inspect your RF conditions, go to your AP's Maintenance::Support Info
page and review the info in the window. AP syslog is the last part of support info,
and the Atheros radio RF statistics section is just above it. Here is an example. The
key is the Histogram, a rolling 2 minute sample of RF conditions. Less than 5K
PHY errors per second is the target for good bridge links.

### Athstats Radio 0 ###

------ Interrupt Stats ------
123688 RX interrupts(rx_i)
141 TX interrupts(tx_i)
1043 beacon alert interrupts(swba)

------------ TX/RX Stats ------------
15 long on-chip tx retries(tx_longretry)
282 tx frames with rts enabled(tx_rts)
21 rts fail count(tx_shortretry)
6% rts fail rate
126 tx frames with 11g protection(tx_protect)
4332 rx failed 'cuz of bad CRC(rx_crcerr)
2 rx failed 'cuz frame too short(rx_tooshort)
15 rx discarded 'cuz frame too large(rx_toobig)

------------ PHY Error Stats ------------
110620 PHY errors since clearing all stats (rx_phyerr)
110573 phy ofdm timing
47 phy zero len crc
1154 PHY errors since clearing delta stats (1 sec)
1154 phy ofdm timing
Histogram of PHY errors per second (pcttime in each range)
0 1-500 ..1K ..2K ..5K ..10K ..20K ..50K .100K more
0 3 50 45 1 0 0 0 0 0

Esteemed Contributor II
Histogram of PHY errors per second (pcttime in each range)
0 1-500 ..1K ..2K ..5K ..10K ..20K ..50K .100K more

Contributor III

unfortunatelly i am not able to use Channel 149-161. Just from 100 to 140.

I checked the Support File:
### Athstats Radio 0 ###

------ Interrupt Stats ------
101471 RX interrupts(rx_i)
41708 TX interrupts(tx_i)
1553 beacon alert interrupts(swba)

------------ TX/RX Stats ------------
6353 long on-chip tx retries(tx_longretry)
0% rts fail rate
12210 rx failed 'cuz of bad CRC(rx_crcerr)

------------ PHY Error Stats ------------
4923 PHY errors since clearing all stats (rx_phyerr)
74 phy radar
4849 phy ofdm timing
45 PHY errors since clearing delta stats (1 sec)
1 phy radar
44 phy ofdm timing
Histogram of PHY errors per second (pcttime in each range)
0 1-500 ..1K ..2K ..5K ..10K ..20K ..50K .100K more
0 100 0 0 0 0 0 0 0 0

Like you described this should be ok.

Other Ideas? Am i able to check if a burst of radar is a factor? Maybe there is a Log-Entry for that? Should my ZF7731 change his operating Channel automatically to another one if there is a Radar or other interference?

Best Regards

Hi Marco,

As per my knowlegde, if ZF7731 detects Radar burst then it logs it which can be seen in the support file logs area.

If ZF7731 or any other vendor device operating on channel which is also used by Radar as per ETSI guidelines "must" vacate that channel irrespective whether that channel is fixed or dynamic if Radar is heard.

You can read more on this here -

same rule does not apply on Non-radar interference and that is left to the discretion of Zf7731 intelligence.

Hope this helps

Esteemed Contributor II
Yes, you can review the System Log messages, that follow the Athstats. Each AP
will report the conditions that affected it, and the association with the opposite 7731.
Maybe date and time stamps can help tell the frequency and occurances.

The bridges may report "badness" and noise floor values. The Root Bridge will
report messages that might suggest a better channel, but it will not change by
itself (which would disrupt traffic), only notifies the admin.