ZF7731 Point to Point Connections gets dropped

  • 1
  • Question
  • Updated 2 years ago
  • Answered
Hello,

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
Marco
Photo of Marco Eichstetter

Marco Eichstetter

  • 152 Posts
  • 8 Reply Likes

Posted 3 years ago

  • 1
Photo of Michael Brado

Michael Brado, Official Rep

  • 2182 Posts
  • 300 Reply Likes
First, get the latest 7731 firmware from the Support Portal Downloads page and
upgrade. Upgrade the far side 7731(s), whether RB or an NRBs, first.

Second, and this might be key to improving your performance, be sure you have
the correct Distance setting on both side 7731s. From Configuration::Wireless,
click Edit Advanced Settings button, for the screen with Distance value setting.
Your 75 meters means use minimum 1KM setting.

Third, use the Channel Optimizer from the RB Status::Wireless page.
This is an intrusive test that will flood the link in both directions with as many
packets as possible in both directions, on every available 5G channel to determine
the best bi-directional throughput one to use.

If you experience further problems, use the Channel Optimizer again, but that
might mean there could be an intermittent source of interference that sometimes
affects your link. I hope this is helpful.
Photo of Marco Eichstetter

Marco Eichstetter

  • 152 Posts
  • 8 Reply Likes
Hi Michael,

thanks for your feedback:
Firmware is already 9.2.0.0.169. This is the latest i found.
Distance is already set to 1km.
I used already the Channel Optimizer.

The Connections gets dropped once a day.
The strange thing is, the Root-Bridge displays an existing connection with full connection signal. But if i want to check the link speed with Speedflex there will be displayed an error the Non-Root-Bridge could not be accessed.

If relevant my Region is "Germany".
I already tried to set a fixed Channel (100) but this did not solve my Problem.

The Best Result whould be if there is no Connection Break, of course.
It whould be also helpful if i dont have to manually restart the Root-Bridge to get my connection back online.

Thanks!
Best Regards
Marco
Photo of Monnat Systems

Monnat Systems, AlphaDog

  • 776 Posts
  • 163 Reply Likes
Marco,

There are some Zf7731 CLI commands which allows to auto restart the either device if link is off for certain configurable period of time. I don't have 7731 handy at the moment so will check it for you once i visit my customer and check for those. this won't be happening until next week. Please check with support team if it is urgent and i think it is a worth while thing to consider & try.

Hope this helps.
Photo of Marco Eichstetter

Marco Eichstetter

  • 152 Posts
  • 8 Reply Likes
Hello Monnat Systems,

it whould be really nice if you can check this on your Customer Installation. I found today i another Forum Topic about a 7731 Installation following CLI Commands. This should do a automatic Reboot if Connections gets down:
Root Bridge :

rkscli: set uplink-recovery sta-link-down-init-time 60
rkscli: set uplink-recovery sta-link-down-reboot-time 60
rkscli: set uplink-recovery no-sta-link-reboot-time 60
rkscli: set uplink-recovery ap-exp-assoc 1
rkscli: set uplink-recovery sta-mia-reboot-time 60

Non Root Bridge :

rkscli: set uplink-recovery sta-link-down-init-time 60
rkscli: set uplink-recovery sta-link-down-reboot-time 60
rkscli: set uplink-recovery no-sta-link-reboot-time 60

In the meanwhile i will open a Support Case. It is a little bit urgent, because my Customer is getting upset.

Thanks a lot!
Best Regards
Marco
Photo of Michael Brado

Michael Brado, Official Rep

  • 2182 Posts
  • 300 Reply Likes
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
Photo of Michael Brado

Michael Brado, Official Rep

  • 2182 Posts
  • 300 Reply Likes
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
Photo of Marco Eichstetter

Marco Eichstetter

  • 152 Posts
  • 8 Reply Likes
Hi,

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?

Thanks!
Best Regards
Marco
Photo of Monnat Systems

Monnat Systems, AlphaDog

  • 776 Posts
  • 163 Reply Likes
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 - http://www.nts.com/pdf/whitepapers/6_...

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

Hope this helps
Photo of Michael Brado

Michael Brado, Official Rep

  • 2182 Posts
  • 300 Reply Likes
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.
Photo of Marco Eichstetter

Marco Eichstetter

  • 152 Posts
  • 8 Reply Likes
Hello,

i just wanted to give some feedback to this Topic.
Meanwhile i created an official Case. After some Investigation we first did not know, why the Connections gets dropped and not come back online. After some internal Disscussion, Ruckus decided to exchange the Hardware because some Log Entries looks like there is a Problem with the Antenna.

Since the new Bridges arrived there was no Outage any more and it seems to work like expected.

Best Regards
Marco
Photo of Michael Brado

Michael Brado, Official Rep

  • 2182 Posts
  • 300 Reply Likes
Thanks for the update!
Photo of support kaldien

support kaldien

  • 1 Post
  • 0 Reply Likes
We had the same issue.  Although these were switched to RTS CTS mode and this fixed the issue for us.  It was a pain to keep rebooting the bridge every time it stopped.