02-20-2017 07:43 AM
First to repeat from earlier posts I made, I am a new Ubiquiti user so am still learning: I had issues with VLAN philosphy and the fact that WAPs don't do management VLANs, but managed to alter my configuration over the whole network, and have it working. Overall, I really like the Ubiquiti product family and the responsiveness of the community, and intend to upgrade my network as the budget allows though we have a limited budget as a not for profit: the IT department (i.e. ME) is entirely voluteer.
Anyway, I have a network in an international women's student residence, 5 floors about 70 total users all with multiple device. Based on limitations of wiring options, I have 10 WAPs, 2 via wireless uplink. I recently upgraded the main POE switch and 2 of the WAPs to Ubiquiti: US-24 switch and AP-Pro WAPs. 1 of the WAPs is using Wireless uplink.
Overall, the people on the new AP Pros loved the performance upgrade, BUT NOW, to the problem:
Some number small number of users have experienced an inability to connect when they are in the building with the AP PROs. I only worked heavily with 1 who has a Macbook Air who could not connect at all. They would get a Wifi connection, they actually get a valid IP for the VLAN their SSID is associated with, but when they try to use it, nothing happens ("not connected to the internet"). I monitored the router (a netgear giga bit load balancing router - a hold over from pre cable days when we had 4 DSL lines, we now use 1 WAN port at 150 Mbs) and their address showed up in the DHCP client list, but then disappeared. This failure mode also occured with a static IP.
It should be noted that most of the students have Macs and I use a Macbook Pro when on site and checking the network. So it's definitely not a general (i.e. every) Mac issue. And the above mentioned student's iPhone was connected and working. When I last checked the Management app it showed 81 connected clients, 46 of which were Apple products. So it seems to be a corner case. It may be some state information that needs to be forcibly reset.
Other relevant information: I tried changing from AES to "auto". I left it WPA2 as the legacy Engenius routers are all WPA2 and this student's mac works on all the legacy routers. That didn't help. I also tried "forget this network" (or rather had the student try it) multiple times, rebooting the entire network and so on.
Finally, I had searched google and this community on the topic of Macs and Ubiquiti and found mixed results, plus the dates and versions of software/firmware were old. I have all the latest firmware and controller software as of 11 Feb 2017. So while the polite thing is to search the archives and only post when necessary, I was having trouble determining what is relevant. So I posted this with the hope that someone can point me at a good capsule summary of what else to try.
02-26-2017 07:33 PM
Similar here, we're seeing what look like mostly Air's with the problem as my Retina and other Pro's seem to work fine, when the students roam is what we think might be the problem also as it tends to be at the start of a period when they have relocated rooms.
We're on 188.8.131.5265 and some 184.108.40.20615 I am yet to find as to whether one is better or worse, am going to try and finish the 6115 out of hours this evening..
Turning wifi on and back on on the Mac seems to resolve the issue.
02-27-2017 01:54 AM
Thanks d-m-z, I have beta access but I've gone 6115 across campus tonight see how it goes tomorrow and if we can replicate it. If we're still having trouble I'll give the beta a go......
02-27-2017 08:33 AM
Thanks for your inputs. My WAPs are still on 3.7.29. The app does not however show update available. I heard of an issue with this version preventing future updates without some serious manual intervention.
I will be on-site tomorrow where I can do the upgrade even with manual intervention required
02-27-2017 09:19 AM
What version is your controller?
Also, I'm not sure what you mean by "this version". There were a few 3.7.3x firmwares that wouldn't upgrade (they would try, but fail). The workaround is jsut to disable the WLAN on them (kicking off clients), do the upgrade, and then reenable WLAN. I believe 3.7.40 forward fixes that. It's in the release notes if you want to check.
02-27-2017 10:01 AM
Sorry, a bit ambiguous. When I said "this version" as rumored to having a problem, I meant "220.127.116.1146" on my AP AC Pro. I haven't tried updating from this version, but the fact that the controller is not showing that an update is available is what lead me to raise the issue at all.
As far as what version controller, I am running a Cloud Key. The firmware version is:
The controller vesion is:
I intended to update when I am on site tomorrow: I have direct access via the iPhone app and update firmware and controller are both available to me, but I'm a bit paranoid about not being in person in case something goes wrong.
Actually that raises a quick question: if I screw up the upgrade of the controller, that should not affect my switch or WAPs, should it? It would save me some on site time if I can do the controller updates "risk free" in advance. While the answer seems obvious, I just don't have the experience with ubiquiti products yet to be confident in the "obvious answer".
02-27-2017 12:21 PM
Since my previous reply, I did pay more attention to the release notes of the controller WRT bundled firmware. I assume that the controller only checks your devices against its bundled firmware which would explain why my current controller doesn't show any. Sorry, still a noob. I will skip the bundled version when I upgrade and try the latest release for the APs.
02-27-2017 04:16 PM
Hey guys, so upon reading a bit it seems to be not specific to UniFi but more about Macbook and perhaps even Air's alone, as I've found a few other forums with the same issue including Aerohive and Aruba.
I have deployed 3.7.42 in the locations we were seeing the problem which are quite high density areas. We've tried to replicate it with a couple of MacBook Air's this morning but they appeared to roam appropriately and behave nicely so we will monitor it closely.
Other tips/tricks have mentioned that whatever chip is in the Air won't like it if there is a lot of high power in a single location, we don't run ours above normal broadcast power but some other vendors were suggesting to turn down the power on the APs output to solve similar symptoms. We do have band steering turned on as well, this was also a suggstion from other vendors to disable so that the Mac's were 'happier'.
Will keep you posted if we find more......... thanks @d-m-z
02-27-2017 08:05 PM
Just a comment about band steering... I find Macs and especially iOS devices are pretty good about choosing 5 GHz when it's available. Just make sure you've turned your 2.4 GHz radio down MORE than the 5 GHz radio. Otherwise 2.4 GHz is going to appear stronger in most places.
02-27-2017 08:07 PM
Controller ... 5.4.11 is the current stable version. And it will upgrade devices to 3.7.40. To go to 3.7.42, you have to sign up for the beta forum, and do a custom upgrade.
I run a controller on AWS so I can't comment on the clould key. If you're not using a captive portal, everything should continue to operate even if the controller / cloud key is non-functional.
02-28-2017 04:15 AM
@d-m-z APs that we went to 42 on worked better today we were still able to replicate the issue with 1 client however the other 5-6 that presented the day earlier worked fine (luckily had the same class same room two days in a row).
I've also had a read I've turned off more of the 2.4 broadasting radios and the remainder down to low power as per your suggestion.
WIll see how we go tomorrow but wsa certainly a step in the right direction.
02-28-2017 04:30 AM
certainly a step in the right direction.
Good to hear. Keep an eye on the beta forum as new firmware gets released semi-regularly.
(or subscribe to the relevant updates blogs https://community.ubnt.com/t5/custom/page/page-id/Blogs to get an email)
03-13-2017 05:59 PM
So this has still been a problem for us but it has been hard to diagnose as students often don't report it which in itself makes it difficult to track success.
I have today gone to 18.104.22.16894 on the affected location and have done some changes to the 2.4 radios in the area. For me this is what we've seen/learnt through the exercise.
- The problem is more related to MacBook Airs (perhaps even exclusively)
- Bandsteering and Airtime fairness have both been trialed and then turned off - it is only a feeling but I felt as though things ran more smoothly without them
- The problem seems to appear when the MacBooks are close to a 2.4 radio - almost like they can't roam away from 2.4 to 5
- When we have defaults of 2.4 and 5 at auto broadcast power there are many more problems
- We do still need to provide 2.4 but have chosen fewer access points to broadcast this frequency and are then set at "Low"
- This seems to have lessened the problem however it still happens on occasion
We are again trying a different configuration, I will let you know how it goes.
03-20-2017 04:23 PM
Thought I would update you on this as I suspected a version of OSX however I've now seen the issue present in El Capitan, Yosemite and Sierra.
Interestingly it seems to be related to wpa enterprise authenticated SSID's as we have put a few students on a PSK SSID and the problem has ceased.
Also seems to be when they roam away from a 2.4 radio and try to join a 5 as previously stated, odd though that it goes away when we use PSK.