Wireless Access

Hey all,

 

Had a brief question for anyone who knew any information about this...

 

In my search to help someone at one of my company's locations with his AppleTV on our guest network, I found that our FW was blocking NTP on IP range 17.x.x.x, both UDP and TCP. I then found out that it was recently set this way as part of our network security tightening procedures and PCI compliancies etc. etc., and after reading about iOS device time drift when not communicating to Apple's NTP server, I wondered if this would affect the device's ability to fast roam (because of strict 802.1x authentication and rad-auth and such) or anything else that might adversely affect the device. Anyone have any dirt on that?

 

Any info would be helpful.

 

Thank you!

Are you saying that your guest network uses dot1x?

Webcore,

Apple TVs do not have batteries so they cannot retain the time and depend on NTP when they start up. Other devices have batteries and do not depend on NTP, per se. You probably have another problem with roaming not occurring properly like (1) AP power too high or (2) Apple firmware not updated to the latest.

@thecompnerd wrote:

Are you saying that your guest network uses dot1x?

 

No, although I have seen that before. Fortunately, we don't run that. My question was more of a generally observed behavior type of question.

 

---

@cjoseph wrote:
Webcore,

Apple TVs do not have batteries so they cannot retain the time and depend on NTP when they start up. Other devices have batteries and do not depend on NTP, per se. You probably have another problem with roaming not occurring properly like (1) AP power too high or (2) Apple firmware not updated to the latest.

---

Colin,

Thanks for your reply. Yes, devices like AppleTVs and iPads don't have internal batteries to regulate their clocks and rely on a homerun back to time.apple.com in order to keep their clock syncronized. Yes, devices that have batteries do a much better job of regulating their clocks, but I can assure you that the roaming problem is not related to too high a Tx EIRP value or the Apple firmware being updated. We've gone so far as to remove 20MHz and 40MHz channel bonding to open up more channels to curb the co-channel interference that we've been seeing at this location, put in more 135 CAPs (the location is now baselined at -60dBm on 5.0GHz), and thoroughly tested our Radius auth at the site and can't find any problems any longer (other than eliminating some legacy switches upstream, but we know about those). I'm simply trying to find any information that would lead me to believe that having no NTP for our iPad Minis (1st and 2nd Gen) at this location may cause authentication issues on one of our 802.1x auth'ed networks; I even read the Radius RFC and I couldn't find anything that could really tell me, and Apple's site is useless with this kind of stuff, so I was looking here to see if anyone could contribute anything from their experience (doesn't even really have to be about wifi Radius auth, it could be AAA wired Rad auth).

 

Also, while I'm at it, I'll also tell you that we ran full 802.11k + r at this location, and 802.11r was causing the iPad Minis to lock upon re-authentication when roaming, pretty much the exact opposite of what was supposed to happen. So, if anyone's looking to use it, unless you have a small network, don't run it. 802.11k is ok, but only with certain devices, the latest drivers, and no Windows 8 systems! (only Windows 8.1).

 

Thank you!

I just re-read your first post and you are saying that you have an issue with fast roaming.  In the post below you say it is a generally observed behavior type of question.  What exactly is your issue?

 

While fast roaming, observed behavior of iPad Minis authenticating on an 802.1x network do not re-auth to the new AP and "hang". If we go into the controller and kill the session, it rejoins straight away. Could this be related to time differentiations between Radius and the iPad mini itself due to the lack of NTP for the iPad Minis?

 

Thank you!

If the time was wrong on the client in  802.1x network, it would see that the server certificate is not valid and would not work period.  Nothing we have seen points to delays.  I would check my 802.1x profile and see if OKC is on (it is on by default), that Valid PMKID is also on.  That is a big cause of roaming issues with IOS/Apple devices on 802.1x.

OKC is disabled, and PMKID is enabled. This is why we tried 802.11k + r.

Webcore,

 

Roaming does work for those devices in Aruba environments today, so the issue is either your environment, your configuration or a combination thereof.  TAC would be the best people to sort it out.  On the forum here, we would only be guessing.

 

 

Yep, I understand. Thanks for the help.