Mesh AP lose connection

[demetris_demetr]

Hello all

i have a setup with a ZD 1200 and 7 T300 APs. It is a mesh setup however 3 of the APs have mesh disabled, 2 act as root APs and 2 as mesh APs with manual AP selection. The issue is that the last 3-4 days i am losing the mesh APs. The root APs look to work fine due to the connected status on the ZD. I receive email notifications about the lost APs sometimes every 30 minutes. First of all i am trying to understand how the notification process works. Please verify or correct me on this. The AP loses heartbeat which actually means lose connection with the ZD. If the connection is not restored within 30 minutes the AP will be restarted. When the ZD lose connection with the mesh AP an email notification will be sent to me. If the connection is never restored the AP will continue to be restarted every 30 minutes and an email will be sent to me every 30 minutes.
Second, if i have a power faillure at the mesh points, will i get the same notification? and i will continue to get the notification every 30 minutes?
Third, is there a way to reject the power faillure scenario from the logs?

Thank you
Demetris

[michael_brado]

You should analyze the Support Info file from your Root APs, and see what RSSI they see your Mesh APs?
Both sides need to see each other at RSSI of 25+ to maintain Mesh links.  If your Mesh APs lose connectivity
they will attempt to recover by advertising Island SSID and rebooting after 30 minutes, correct.

[demetris_demetr]

Ok, i am returning with more questions 🙂

first of all i saw those two entries

Nov  1 06:06:12 RuckusAP daemon.warn Eved: STA-DISASSOC-REASON [ieee80211_send_mgmt(),4698,send station disassociate] 48:50:73:ff:74:b8 rx_rssi=9,ack_rssi=0,reason=1,freq=2412,chan=1,rx pkt,byte;tx pkt,byte=(50,6611,117,8835)
Nov  1 06:06:12 RuckusAP daemon.info matrix: Adding peer AP.1C:B9:C4:26:63:E0 (10.0.0.16) for PID 498 (func=avpd_roam_sync_req, line=794) ...

This is what you mean about the RSSI? so this is the reason i have disconnections?
I just checked the signal i get on those 2 mesh APs. On the one is average 77% and on the other average 82%. I believe is good, isn't it? (i can have speedflex speedtest 200'Mbps on each way) So if the APs are installed on places with high altitude and free LOS why i might get the signal dropped?

What i noticed is something that has to do with the radar scanning

Nov  1 01:02:56 RuckusAP daemon.notice meshd[421]: RADAR-CLEARED.indication: Channel 116
Nov  1 01:02:56 RuckusAP daemon.warn Eved: wifi1: RADAR-CLEARED.indication: Channel 116
Nov  1 01:02:56 RuckusAP daemon.warn Eved: wifi1: RADAR-CLEARED.indication: Channel 120
Nov  1 01:02:56 RuckusAP daemon.warn Eved: wifi1: RADAR-CLEARED.indication: Channel 124
Nov  1 01:02:56 RuckusAP user.warn kernel: Cleared channel 116 of RADAR
Nov  1 01:02:56 RuckusAP user.warn kernel: Cleared channel 120 of RADAR
Nov  1 01:02:56 RuckusAP user.warn kernel: Cleared channel 124 of RADAR
Nov  1 01:02:56 RuckusAP user.warn kernel: Cleared channel 128 of RADAR
Nov  1 01:02:56 RuckusAP daemon.notice meshd[421]: RADAR-CLEARED.indication: Channel 120
Nov  1 01:02:56 RuckusAP daemon.notice meshd[421]: RADAR-CLEARED.indication: Channel 124
Nov  1 01:02:56 RuckusAP daemon.notice meshd[421]: RADAR-CLEARED.indication: Channel 128
Nov  1 01:02:56 RuckusAP daemon.warn Eved: wifi1: RADAR-CLEARED.indication: Channel 128

Is there any chance that a radar in the neighbourhood and the use of the "Enable radar avoidance pre-scanning" can cause this interruption?

thank you

[michael_brado]

The analysis I meant, was the individual Root AP and Mesh AP's support info files, which should show each other as clients on 5GHz radios.

STA: b8:e8:56:2c:55:10
    rx_data_frm 229462 rx_mgt_frm 38 rx_bytes 37430154 rx_dup 9
    tx_data_frm 464364 tx_mgmt_frm 40 tx_bytes 535238276
    tx_assoc 4 tx_auth 4
    good_tx_frms 464404 good_rx_frms 229500 tx_retries 40825
    tx_rate 324000 tx_kbps 155352
    tx_per 1 ack_rssi 39 rx_rssi 44

For example, this associated client (but could be other AP) has rx_rssi = 44, which is > 25 after you subtract the PER (packet error rate), in this client only 1%.
Examine the same detail on the other side Mesh AP, for the Root AP mac address.  The rx_rssi minus PER must be greater than 25 to maintain Mesh connectivity.

Second advice, the messages do indicate DFS recognized radar in use near your APs, and assigning static channels outside of DFS range might be advisable.
Reboot your Root APs a couple times, and make note of which 5GHz channel they choose when they come back up.
Under Configure/Access Points, 'Edit' your Root APs, check Override Group Settings, and manually pick from 149, 153, 157, 161.
After one of your Root APs is statically configured, reboot the other Root AP and make note of its chosen channel.  Set it to one different than Root AP#1.

[demetris_demetr]

My problem is fixed and i wanted to let the community know which was the issue. The system scans 5GHz channels for radar and if there is something on that channel, the channel i blocked for the period of time (don't know how much time). My system was scanning the channels and was facing radar interference in all channels therefore was blocking them and no channel was left to establish the link. The issue is solved as soon as i allowed my APs to use the indoor 5GHz channels. For some reason disabling the "Radar Avoidance Pre-Scanning" setting wasn't helpful. In addition i found it strange to have radar and that specific area (and on all channels)