03-09-2015 06:47 PM
Ok, guess or fact?
Either way, not really enough information.. If we know where the problems are we know whether to stop working on the difficult issues we are troubleshooting.
In particular fast roaming looks broken on 188.8.131.52.
03-09-2015 08:32 PM
The reason it was pulled was not specifically related to fast roaming. If you are still concerned whether 184.108.40.206 is the cause of your current issues, your best course of action is to open a TAC case. 220.127.116.11 (with specific fixes for the issue identified in 18.104.22.168) is expected for release this week.
Systems Engineer, Northeast USA
ACCX | ACDX | ACMX
03-10-2015 12:04 PM
About 3 or 4 weeks ago, just before our spring break, I upgraded our entire district wireless IAP infrastructure (roughly 1900 APs) from 22.214.171.124-126.96.36.199_46936 to 188.8.131.52-184.108.40.206_48114. A day or two after spring break was over, we started having some issues where random APs seemed to stop passing DHCP traffic. Clients were getting 169.254 (automatic private) IP addresses, and couldn't connect to the network. Rebooting the AP would solve the problem for a couple of days. I opened a TAC case (#1650699 if anyone with TAC access wants to check out the history), but then the problem became a major epidemic. Last week, while I was at Atmosphere 2015, I had to remove in (thank goodness for VPNs) and initiate a district-wide downgrade (thank goodness for Airwave!) back to 220.127.116.11-18.104.22.168_46936. Since then, we've had no problems.
I suspect that perhaps this could be another reason why 22.214.171.124-126.96.36.199_48114 was pulled...??
03-11-2015 11:05 AM
Update: My DHCP problem doesn't seem to be limited to 188.8.131.52_48114. The problem just happened again today at multiple site, with the previous code version. I still have an open TAC case, but will post a separate thread here as well.