Wireless Access

Hello All,

I am having a customer using AP225 as a remote AP bridge mode, client in use is iPad and iPhone on IOS 7. When the client goes idling after 30 minutes or so the client cannot connect back to the wireless. Although we can see from debug the 802.1x has been sent to the controller and to the Radius (Steelbelt Radius) but we couldn;t see the success on the radius on the debug. Only after we switch off and on the WLAN on the client then it is able to get authenticated sucessfully.

The way out of this is to remove all the WLAN profile on the iPad and iPhone then even after the client when idling for any amount of time it is able to get connected back to the WLAN. Anyone is having the same issue and is there any other solution to this problem.

AirOS in use is 6.3.1.2, controller is 7210, AP is 225 in bridge mode.

FYI, tested on Samsung Note 8.0 and 10 is working fine even with multiple WLAN profiles.

• Did u change anything in the logon role?
• What are your AAA timers?
• Can u please printout the all your Access roles/AAA profiles/VAP configuration your are using.

Hello kdisc98

Nothing change on the logon role.

(Controller) #show aaa timers

Global User idle timeout = 300 seconds Auth Server dead time = 10 minutes Logon user lifetime = 5 minutes User Interim stats frequency = 600 seconds

user-role denyall

user-role logon
 captive-portal "default"
 access-list session ra-guard
 access-list session logon-control
 access-list session captiveportal
 access-list session vpnlogon
 access-list session v6-logon-control
 access-list session captiveportal6

user-role SH-Shop-Authenticated
 access-list session allowall

wlan virtual-ap "St_Shop_Corp"
   aaa-profile "St_Shop-aaa_prof"
   ssid-profile "St_Shop_Corp-ssid-prof"
   vlan 230
   forward-mode bridge
   allowed-band a
   no broadcast-filter arp
   auth-failure-blacklist-time 5
   blacklist-time 5
   no mobile-ip
   vlan-mobility

aaa profile "St_Shop-aaa_prof"
   initial-role "denyall"
   authentication-mac "St_Shop_MAC-prof"
   mac-default-role "SH-Shop-Authenticated"
   mac-server-group "St_Shop_rad-server"
   authentication-dot1x "St-PS-PSK-Profile"
   dot1x-default-role "logon"

wlan ssid-profile "St_Shop_Corp-ssid-prof"
   essid St@PS
   opmode wpa2-psk-aes
   a-tx-rates 36 48 54
   max-clients 128
   no disable-probe-retry
   wpa-passphrase c5f059c561181e2f317411b407609ccb8955b1048bc374ff99ce9ecf445ef35793c74b62c89f3b03

Hope this is enough.

Let me change it and then revert. Thanks

what exactly is this setup? i see mac auth roles, i see captive portal profiles, i see you mention dot1x, it feels like a lot of unneeded extras are configured here.

could you explain what exactly the required authentication setup should be?

@kdisc98 on what do you base the initial role should be changed? it works on android like this, why would changing this role help with IOS?

Hello Boneyard,

Yes, some unnecessary, we are using 802.1x not MAC auth here.

Normal Guy,

It is not clear what you are presenting us with here.  You should show us the role that a user gets when he/she is authenticated and type "show rights <role>" so that we can see the ACL involved.

If you are bridging user traffic, why would the 802.1x default role be logon?  That makes no sense.  You cannot do captive portal on a bridged SSID!  If the user gets a different role than the 802.1x default role, please show us the ACLS from THAT role..

Why do you have the a-tx-rates manipulated, but not the corresponding basic rates or the beacon rates?

a-tx-rates 36 48 54

Why is broadcast filter ARP off?

Each one of these presents issues by itself!

Hi Joseph,

Thanks as we have gotten this controller from another vendor and there is a need for clean up. Let me do some clean up and then advise. Mainly device getting connected is via iPad doing 802.1x using Stealbelt radius with MAC address as the username and password. Since this is bridge mode no CP is enabled and we cannot see the role of the client via show user.

Not true.  Bridged clients show up in the user table with a forwarding mode of bridge.

It would seem that you need to first clean up the customer configuration and then attempt to replicate the IOS7 issue.  THEN if you still can replicate it, post questions about things that do not seem right.  It would take more time to post parts of a problem configuration and have the forum guess what the probem could be...

Hello Joseph

a-tx-rates 36 48 54

We are making sure that the connect at high rate and not the low rates but this will set back to usual as it is not the issue.

Why is broadcast filter ARP off?

Roaming from A radio when this is on it is disconnect and doesn't reconnect.

You will only get the actual benefit if you change the basic rates, as well http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Dramatic-utilization-reduction-in-2-4GHz-spectrum/m-p/92186/highlight/true#M2947

Broadcast Filter ARP has no effect in bridge mode, but it should not be turned off.