Controllerless Networks

Hi All,

I'm getting a wierd issue where my mesh point and portal disconnect for about a minute, recover, then 15 minutes later do it again. Users connected to the mesh point AP do not have access to the gateway so they are getting frustrated with minor interruptions.

I have some syslogs being sent and every time before I get a disconnect on my continuous ping I see the following series of events in order from top to bottom:

Version 6.4.4.3-4.2.2.1_53878

Mesh Portal IP 192.168.1.51 - IAP 205

Mesh Point IP 192.168.1.52 - IAP 225

1. 02-29-2016 21:18:43 Local1.Warning 192.168.3.51 Feb 29 21:18:42 2016 192.168.3.51 sapd[1941]: <404093> <WARN> <192.168.3.51 40:E3:D6:CF:>  AM 40:e3:d6:72:72:50: ARM HT Empty Channel Trigger new 52E/0/0 old 132E/53/0 new_rra 52E/8

2. 02-29-2016 21:19:19 Local1.Warning 192.168.3.52 Feb 29 21:19:18 2016 192.168.3.52 cli[3405]: <341135> <WARN> <192.168.3.52 84:D4:7E:C5:>  Master Changed - new 0.0.0.0 old 192.168.3.51 current swarm state 3.

3. 02-29-2016 21:19:20 Local1.Warning 192.168.3.52 Feb 29 21:19:19 2016 192.168.3.52 cli[3405]: <341135> <WARN> <192.168.3.52 84:D4:7E:C5:>  Master Changed - new 0.0.0.0 old 192.168.3.51 current swarm state 0.

4. 02-29-2016 21:19:44 Local1.Warning 192.168.3.52 Feb 29 21:19:43 2016 192.168.3.52 cli[3405]: <341004> <WARN> <192.168.3.52 84:D4:7E:C5:>  Swarm State Change from Startup to Found

5. 02-29-2016 21:19:45 Local1.Warning 192.168.3.51 Feb 29 21:19:45 2016 192.168.3.51 cli[1925]: <341097> <WARN> <192.168.3.51 40:E3:D6:CF:>  recv_image_check: mac-84:d4:7e:c5:e9:c4, version-6.4.4.3-4.2.2.1_53878, ccode_idx-0.

6. 02-29-2016 21:19:45 Local1.Warning 192.168.3.51 Feb 29 21:19:45 2016 192.168.3.51 cli[1925]: <341165> <WARN> <192.168.3.51 40:E3:D6:CF:>  send image match to 192.168.3.52.

7. 02-29-2016 21:19:45 Local1.Warning 192.168.3.52 Feb 29 21:19:45 2016 192.168.3.52 cli[3405]: <341004> <WARN> <192.168.3.52 84:D4:7E:C5:>  Swarm State Change from Found to Image_ok

8. 02-29-2016 21:19:51 Local1.Warning 192.168.3.52 Feb 29 21:19:50 2016 192.168.3.52 cli[3405]: <341004> <WARN> <192.168.3.52 84:D4:7E:C5:>  recv_config_init: config isn't changed; skip config and change to sync complete

9. 02-29-2016 21:19:51 Local1.Warning 192.168.3.51 Feb 29 21:19:50 2016 192.168.3.51 cli[1925]: <341199> <WARN> <192.168.3.51 40:E3:D6:CF:>  send_config_init: send config to slave 192.168.3.52, using url 0, auto save disable 0.

Is ARM causing channels to switch due to interference and causing my disconnects? 

Thank you,

N

I would uncheck 80mhz channels in RF > ARM to make things more stable, for now.  

I would also go to RF > ARM >Show advanced options and make sure "Client Aware" is checked so that the access point does not attempt to change channels when there are clients on it.

Your AP changed channels because it saw an "empty" channel.  This forced a Virtual controller election, which caused the VC to be taken over by the other access point.

Unchecking 80 mhz channels gives interference a smaller footprint to operate in statistically.  Turning on Client Aware will keep your access point from changing channels while clients are attached...most of the time.

Try those two changes

Will client aware do anything for desktops that are connected via the mesh point? I currently have 0 active wireless clients but pings on the remote workstation still drop out (prior to making the settings you suggested).

Client aware is already enabled.

Interestingly enough, as soon as I disabled "80Mhz support" I started to get mac associations in the syslog for the desktop computers.

1. 02-29-2016 22:18:44 Local1.Warning 192.168.3.52 Feb 29 22:18:44 2016 192.168.3.52 cli[3405]: <541004> <WARN> <192.168.3.52 84:D4:7E:C5:>  recv_sta_online: receive station msg, mac-00:1f:bc:00: bssid-84:d4:7e:c5: essid-__wired__eth0.

2. 02-29-2016 22:18:44 Local1.Warning 192.168.3.52 Feb 29 22:18:44 2016 192.168.3.52 cli[3405]: <541013> <WARN> <192.168.3.52 84:D4:7E:C5:>  recv_sta_online,1186: add client 00:1f:bc:00:, client count 1.

I will test and report back, thank you.

N

It's still happening although less often. I still see empty channel messages and then a loss of connectivity.

N

What is your regulatory domain?  It says that you are using DFS channels. 

Allowed Channels for AP Type 205 Country Code US
------------------------------------------------
PHY Type Allowed Channels
-------- ----------------
802.11g (indoor) 1 2 3 4 5 6 7 8 9 10 11
802.11a (indoor) 36 40 44 48 52 56 60 64 100 104 108 112 116 132 136 140 144 149 153 157 161 165
802.11g (outdoor) 1 2 3 4 5 6 7 8 9 10 11
802.11a (outdoor) 36 40 44 48 52 56 60 64 100 104 108 112 116 132 136 140 144 149 153 157 161 165
802.11g 40MHz (indoor) 1-5 2-6 3-7 4-8 5-9 6-10 7-11
802.11a 40MHz (indoor) 36-40 44-48 52-56 60-64 100-104 108-112 132-136 140-144 149-153 157-161
802.11g 40MHz (outdoor) 1-5 2-6 3-7 4-8 5-9 6-10 7-11
802.11a 40MHz (outdoor) 36-40 44-48 52-56 60-64 100-104 108-112 132-136 140-144 149-153 157-161
802.11a 80MHz (indoor) 36-48 52-64 100-112 132-144 149-161
802.11a 80MHz (outdoor) 36-48 52-64 100-112 132-144 149-161
802.11a (DFS) 52 56 60 64 100 104 108 112 116 132 136 140 144

They are about 25 feet apart, ceiling mounted, one wall between.

It is a small 2 AP deployment, 6 total users (3 desktops). There is a requirement for mesh as the end of the office needs desktops but ethernet cannot be run.

Desktops > Netgear switch > Mesh Point (225) > Mesh Portal(205) > Ubiquiti Firewall > Internet Router

N

I would put the 5Ghz radio on a static channel (disable ARM) in case the mesh link is dropping as the 5Ghz radio is scanning. 

That seems to work better, but if I start to add more APs wouldnt that cause all of the APs in the VC to channel overlap on 5ghz? (assuming there is only one mesh point/portal in the topology).

It just depends on the topology of how the APs are deployed. You would just want to do a per-AP static channel for each AP you want to run as a portal.

That will probably work better than setting the entire VC cluster to just work on one channel. I did that. It seems to work a lot better.

Is there any good way to troubleshoot why arm would be switching to an empty channel so often?

With IAP there is no functionality that prohibits an AP from changing channels when mesh is enabled (not really for AOS either). So if there's no clients on the 5Ghz radio (assuming you have client aware enabled) if the AP scans for 5Ghz and finds a 'better' 5Ghz channel, it will move, even with mesh enabled, and it's obviously very disruptive. In many cases the 5GHz mesh for instant is used when they just need to reach the last leg for client access Aps, but for bridged network backhaul, when you want the 5GHz radio to chose stability over the best channel, a static assignment should be used. It would be good to have some kind of logic where 'is mesh is enabled on the 5Ghz radio, only change channel if absolutely necessary'. It's something I will add to my wish list :)

That would be a great feature, or if client aware took into account wired users.

Thanks

N

Agreed, and it's on my list to discuss with the descision makers next week at Atmosphere. it's just a tricky wicket to kill, but I think we can make it work (at least make it MORE resilient than it is right noe heh).