ArubaOS and Controllers

Reply
New Contributor
Posts: 3
Registered: ‎05-15-2009

iPhone 3.0 unable to stay connected

Hi, all.

We're seeing widespread issues with iPhones unable to stay connected. Association and auth works fine, as does role derivation. Then the iPhone sends a deauth request, with which Aruba happily complies. iPhone OS 2.x doesn't have this problem, and it seems to effect all hardware (1g, 2g, 3g, and 3gs).

Anyone else seeing this? Here is a debug log (IPs have been redacted):

Jul 8 15:31:26 authmgr MAC=00:26:4a:bf:ff:87 def_vlan 666 derive vlan: 800 auth_type 4 auth_subtype 4
Jul 8 15:31:26 authmgr MAC=00:26:4a:bf:ff:87 Station authenticated: method=802.1x, role=FH-Employee-Role, VLAN=666/800/800
Jul 8 15:32:24 stm Disassoc from sta: 00:26:4a:bf:ff:87: AP 10.24.6.18-00:1a:1e:80:8a:60-STL-14-NE Reason STA has left and is disassocisted
Jul 8 15:32:24 stm Sending STA 00:26:4a:bf:ff:87 message to Auth and Mobility Unicast Encr WPA2 8021X AES Multicast Encr WPA2 8021X AES VLAN 0x320
Jul 8 15:32:24 mobileip Station 00:26:4a:bf:ff:87, 0.0.0.0: Received disassociation on ESSID: SwitchedOn Mobility service ON, HA Discovery on Association Off, Fastroaming Disabled, AP: Name STL-14-NE Group STL-14-AP-Group BSSID 00:1a:1e:80:8a:60, phy g, VLAN 800
Jul 8 15:32:24 mobileip Station 00:26:4a:bf:ff:87, 0.0.0.0: Mobility trail, on switch x.x.x.x, VLAN 800, AP STL-14-NE, SwitchedOn/00:1a:1e:80:8a:60/g
Jul 8 15:32:24 authmgr MAC=00:26:4a:bf:ff:87 Station DN: BSSID=00:1a:1e:80:8a:60 ESSID=SwitchedOn VLAN=800 AP-name=STL-14-NE
Jul 8 15:32:24 authmgr MAC=00:26:4a:bf:ff:87 ingress 0x10b4 (tunnel 84), u_encr 64, m_encr 64, slotport 0x1000
Jul 8 15:32:24 stm Station 00:26:4a:bf:ff:87: Clearing state
Jul 8 15:32:28 stm Assoc request: 00:26:4a:bf:ff:87: AP 10.24.6.18-00:1a:1e:80:8a:60-STL-14-NE
Jul 8 15:32:28 stm Assoc success: 00:26:4a:bf:ff:87: AP 10.24.6.18-00:1a:1e:80:8a:60-STL-14-NE
Jul 8 15:32:28 stm Sending STA 00:26:4a:bf:ff:87 message to Auth and Mobility Unicast Encr WPA2 8021X AES Multicast Encr WPA2 8021X AES VLAN 0x29a
Jul 8 15:32:28 mobileip Station 00:26:4a:bf:ff:87, 0.0.0.0: Received association on ESSID: SwitchedOn Mobility service ON, HA Discovery on Association Off, Fastroaming Disabled, AP: Name STL-14-NE Group STL-14-AP-Group BSSID 00:1a:1e:80:8a:60, phy g, VLAN 666
Jul 8 15:32:28 mobileip Station 00:26:4a:bf:ff:87, 0.0.0.0: Mobility trail, on switch x.x.x.x, VLAN 666, AP STL-14-NE, SwitchedOn/00:1a:1e:80:8a:60/g
Jul 8 15:32:28 authmgr MAC=00:26:4a:bf:ff:87 Station UP: BSSID=00:1a:1e:80:8a:60 ESSID=SwitchedOn VLAN=666 AP-name=STL-14-NE
Jul 8 15:32:28 authmgr MAC=00:26:4a:bf:ff:87 ingress 0x10b4 (tunnel 84), u_encr 64, m_encr 64, slotport 0x1000
Jul 8 15:32:28 authmgr 00:26:4a:bf:ff:87: Sending STM new vlan info: vlan 800, AP 00:1a:1e:80:8a:60
Jul 8 15:32:28 stm Sending SAPCP Tunnel Update to 00:26:4a:bf:ff:87 from AP 00:1a:1e:80:8a:60
Jul 8 15:32:28 authmgr MAC=00:26:4a:bf:ff:87 Station authenticated: method=802.1x, role=FH-Employee-Role, VLAN=666/800/800
Jul 8 15:32:28 authmgr MAC=00:26:4a:bf:ff:87 def_vlan 666 derive vlan: 800 auth_type 4 auth_subtype 4
Jul 8 15:32:29 authmgr MAC=00:26:4a:bf:ff:87 IP=0.0.0.0 Authentication result=Authentication Successful method=802.1x server=stlauthdc1
Jul 8 15:32:29 authmgr MAC=00:26:4a:bf:ff:87 IP=0.0.0.0 Derived role 'root' from server rules: server-group=FH-server-group, authentication=802.1x
Jul 8 15:32:29 authmgr MAC=00:26:4a:bf:ff:87 IP=0.0.0.0 Derived unknown role 'root' from server rules: server-group=FH-server-group, authentication=802.1x
Jul 8 15:32:29 authmgr MAC=00:26:4a:bf:ff:87 def_vlan 666 derive vlan: 800 auth_type 4 auth_subtype 4
Jul 8 15:32:29 authmgr MAC=00:26:4a:bf:ff:87 Station authenticated: method=802.1x, role=FH-Employee-Role, VLAN=666/800/800
Jul 8 15:32:55 stm Deauth to sta: 00:26:4a:bf:ff:87: Ageout AP x.x.x.x-00:1a:1e:80:7c:e0-STL-14-ENE handle_sapcp
Jul 8 15:32:55 stm Deauth to sta: 00:26:4a:bf:ff:87: Ageout AP x.x.x.x-00:1a:1e:80:7c:e0-STL-14-ENE Denied; Ageout
Jul 8 15:33:28 stm Disassoc from sta: 00:26:4a:bf:ff:87: AP x.x.x.x-00:1a:1e:80:8a:60-STL-14-NE Reason STA has left and is disassocisted
Jul 8 15:33:28 stm Sending STA 00:26:4a:bf:ff:87 message to Auth and Mobility Unicast Encr WPA2 8021X AES Multicast Encr WPA2 8021X AES VLAN 0x320
Jul 8 15:33:28 stm Station 00:26:4a:bf:ff:87: Clearing state
Jul 8 15:33:28 mobileip Station 00:26:4a:bf:ff:87, 0.0.0.0: Received disassociation on ESSID: SwitchedOn Mobility service ON, HA Discovery on Association Off, Fastroaming Disabled, AP: Name STL-14-NE Group STL-14-AP-Group BSSID 00:1a:1e:80:8a:60, phy g, VLAN 800
Jul 8 15:33:28 mobileip Station 00:26:4a:bf:ff:87, 0.0.0.0: Mobility trail, on switch x.x.x.x, VLAN 800, AP STL-14-NE, SwitchedOn/00:1a:1e:80:8a:60/g
Jul 8 15:33:28 authmgr MAC=00:26:4a:bf:ff:87 Station DN: BSSID=00:1a:1e:80:8a:60 ESSID=SwitchedOn VLAN=800 AP-name=STL-14-NE
Jul 8 15:33:28 authmgr MAC=00:26:4a:bf:ff:87 ingress 0x10b4 (tunnel 84), u_encr 64, m_encr 64, slotport 0x1000
Guru Elite
Posts: 20,553
Registered: ‎03-29-2007

One thing that sticks out

According to these lines:


Jul 8 15:32:29 authmgr MAC=00:26:4a:bf:ff:87 IP=0.0.0.0 Derived unknown role 'root' from server rules: server-group=FH-server-group, authentication=802.1x

You are trying to assign the device to the role "root" for some reason. As you can see, it says that role is nonexistent. Most likely no traffic is going to pass, as a result. That derivation role is in the server-group FH-server-group. You might want to change that to an existing user role.


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

New Contributor
Posts: 3
Registered: ‎05-15-2009

Re: iPhone 3.0 unable to stay connected

Well, that role is local to the controller, and only impacts what access you get in the GUI. It is based on AD group memberships that are returned as Class-IDs from the RADIUS controller.

Everyone gets put into the same wireless user role once authentication has passed. You can additionally get some level of Aruba GUI access based on the server roles. Since my AD user account has membership in the AD group that returns the 'root' role, I get root access at the GUI.

This looks odd, I know, but the same behavior happens if we use a local db account and connect to a totally unsecured SSID. This suggests to me that this has nothing to do with 802.1x, our auth scheme, etc.
Contributor I
Posts: 36
Registered: ‎10-27-2007

Re: iPhone 3.0 unable to stay connected

We've noticed that iPhones running OS 3.0 seem to be less sensitive or rather less tolerant of weak signals. We had one case where the user was in a room with relatively low signal and the iPhone worked fine with OS 2.0 but the network wasn't discoverable after upgrading to 3.0. I've heard other reports of wireless networks "showing fewer bars" after the update.

(I worked around the one case by handing them an AP-60 to keep in their office until I get around to fixing their building. The problem predictably went away. *cough*)
New Contributor
Posts: 3
Registered: ‎05-15-2009

Re: iPhone 3.0 unable to stay connected

That's very interesting regarding signal strength...I think I have a spare AP125 sitting around. Maybe I'll throw that in our VAP and see how it goes...
Guru Elite
Posts: 20,553
Registered: ‎03-29-2007

802.1x


Well, that role is local to the controller, and only impacts what access you get in the GUI. It is based on AD group memberships that are returned as Class-IDs from the RADIUS controller.

Everyone gets put into the same wireless user role once authentication has passed. You can additionally get some level of Aruba GUI access based on the server roles. Since my AD user account has membership in the AD group that returns the 'root' role, I get root access at the GUI.

This looks odd, I know, but the same behavior happens if we use a local db account and connect to a totally unsecured SSID. This suggests to me that this has nothing to do with 802.1x, our auth scheme, etc.




Does 802.1x work for you on any other device? The root role is a role for management ONLY and it is not for 802.1x USERS. According to that audit trail, the device NEVER gets an IP address, because the role and firewall policies attached are invalid, so no traffic passes. Try your user account on another device and see if it works. If it does, publish another user-debug from a different user with an iPhone and we will compare.


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Search Airheads
Showing results for 
Search instead for 
Did you mean: