Wireless Access

Reply
Contributor II

new AP225 deployment with 802.1x on b/g

We just finished switching an entire building over to AP225's and we also turned off our open-SSID that most people used.  In the building with only AP225s the clients (Mac, PC, IOS, Andriod) could only connect to the Guest SSID and not the .1x SSID.

 

What I found was the 'a' radio profile had been in monitor-only mode (an old setting from the AP-70s that were in there).  Once I turned on the 'a' radio most clients could then connect fine to the secure SSID.  

 

The Dell laptops were still unable to connect (forget the model):

  • The could see the SSID just fine
  • The login would hit ClearPass and Authenticate successful
  • The debug logs on the Aruba showed everything was correct and the VLAN set
  • The client would never hit the DHCP server - they would just never ask for an IP

Before the 'a' radio was on all of the clients had the exact symptoms, but only on the secure .1x network - the Guest SSID would DHCPREQUEST perfectly.

 

I then changed the 802.1a RF profile to have a default channel: 36 and Width: 80MHz and now all the clients work (so far every time).

 

For some odd reason it seems like with the AP225's I'm unable to connect a client to an 802.1x SSID on the 'b/g' band.  I'm still testing to see if I'm crazy.

 

Current Setup:

  • ArubaOS 6.3.1.5
  • AP225s
  • CPPM 6.3.4.64924

AP225-set.png

Re: new AP225 deployment with 802.1x on b/g

From the commandline, pick an AP-225 name you want to test and run 'show ap bss-table | include <ap225-name>' and make sure your dot1x SSIDs are even being boradcast. If they are, then you may want to log in to the controller terminating the APs and look at the 'show auth-tracebuf | include <client-mac>' to validate that it's attempting to authenticate to your RADIUS server.

 

Edit, also in your above screenshot, while you can set the channel and channel-width in the radio profile, ARM actually dictates what they run on (unless you disabled ARM). It might be good to get us the entire output of your 'show ap active' output to verify that the APs are all running on, and picking appropriate channels.

Jerrod Howard
Sr. Technical Marketing Engineer
Contributor II

Re: new AP225 deployment with 802.1x on b/g

(Aruba-M3-master) #show ap bss-table ap-name Bea-3-Rm334.32ca
Aruba AP BSS Table
------------------
bss ess port ip phy type ch/EIRP/max-EIRP cur-cl ap name in-t(s) tot-t mtu acl-state acl fm
--- --- ---- -- --- ---- ---------------- ------ ------- ------- ----- --- --------- --- --
18:64:72:03:2c:a1 HCWireless N/A 10.96.97.226 g ap 1/21/21 0 Bea-3-Rm334.32ca 0 1d:0h:18m:15s 1500 - 1 T
18:64:72:03:2c:a2 HCGuest N/A 10.96.97.226 g ap 1/21/21 0 Bea-3-Rm334.32ca 0 1d:0h:18m:15s 1500 - 74 T
18:64:72:03:2c:b1 HCWireless N/A 10.96.97.226 a-VHT ap 36E/21/21 0 Bea-3-Rm334.32ca 0 1d:19h:24m:12s 1500 - 1 T
18:64:72:03:2c:b2 HCGuest N/A 10.96.97.226 a-VHT ap 36E/21/21 0 Bea-3-Rm334.32ca 0 1d:19h:24m:12s 1500 - 74 T

(ArubaM3-1) #show ap bss-table ap-name Bea-4-Rm407a.6d84
------------------
bss ess port ip phy type ch/EIRP/max-EIRP cur-cl ap name in-t(s) tot-t mtu acl-state acl fm
--- --- ---- -- --- ---- ---------------- ------ ------- ------- ----- --- --------- --- --
18:64:72:f6:d8:41 HCWireless N/A 10.96.98.224 g ap 8/21/21 3 Bea-4-Rm407a.6d84 0 23h:32m:32s 1500 - 1 T
18:64:72:f6:d8:42 HCGuest N/A 10.96.98.224 g ap 8/21/21 1 Bea-4-Rm407a.6d84 0 23h:32m:32s 1500 - 77 T
18:64:72:f6:d8:51 HCWireless N/A 10.96.98.224 a-VHT ap 161E/22/22 0 Bea-4-Rm407a.6d84 0 23h:32m:32s 1500 - 1 T
18:64:72:f6:d8:52 HCGuest N/A 10.96.98.224 a-VHT ap 161E/22/22 0 Bea-4-Rm407a.6d84 0 23h:32m:32s 1500 - 77 T

Num APs:4
Num Associations:4

(ArubaM3-1)#show auth-tracebuf | include 18:64:72:f6:d8:41
Jul 30 09:04:08 station-up * 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 - - wpa2 aes
Jul 30 09:04:08 eap-id-req <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 1 5
Jul 30 09:04:08 eap-start -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 - -
Jul 30 09:04:08 eap-id-req <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 1 5
Jul 30 09:04:08 eap-id-resp -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 1 15 csilabwifi
Jul 30 09:04:08 rad-req -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 65477 212
Jul 30 09:04:08 eap-id-resp -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 1 15 csilabwifi
Jul 30 09:04:08 rad-resp <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41/10.108.193.106 65477 76
Jul 30 09:04:08 eap-req <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 2 6
Jul 30 09:04:10 eap-resp -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 2 105
Jul 30 09:04:10 rad-req -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41/10.108.193.106 92 332
Jul 30 09:04:10 rad-resp <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41/10.108.193.106 92 1112
Jul 30 09:04:10 eap-req <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 3 1034
Jul 30 09:04:10 eap-resp -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 3 6
Jul 30 09:04:10 rad-req -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41/10.108.193.106 65535 233
Jul 30 09:04:10 rad-resp <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41/10.108.193.106 65535 1108
...

(ArubaM3-1) #show ap active | include Bea
Bea-2-Rm214.6d0a Beaven 10.96.118.184 0 AP:11/21/21 0 AP:VHT:149E/22/22 225 Aa 1d:20h:22m:24s N/A
Bea-3-Rm321..6bc2 Beaven 10.96.106.209 1 AP:1/21/21 1 AP:VHT:36E/21/21 225 Aa 1d:20h:23m:57s N/A
Bea-2-Ha228.6c9c Beaven 10.96.104.213 0 AP:8/21/21 0 AP:VHT:149E/22/22 225 Aa 1d:20h:22m:12s N/A
Bea-4-Rm409b.6dbc Beaven 10.96.100.220 2 AP:11/21/21 1 AP:VHT:149E/21/22 225 Aa 1d:20h:23m:9s N/A
Bea-4-Rm407a.6d84 Beaven 10.96.98.224 2 AP:8/21/21 0 AP:VHT:161E/22/22 225 Aa 1d:20h:23m:10s N/A
Bea-3-Ha305.6ba0 Beaven 10.96.107.207 3 AP:1/21/21 1 AP:VHT:157E/21/22 225 Aa 1d:20h:22m:26s N/A

 Everything looks good on those from what I can see.  The APs are split across two controllers - but their outputs look similar. 

 

 

Guru Elite

Re: new AP225 deployment with 802.1x on b/g

Not enough information.  Please open a support case in parallel.



Colin Joseph
Aruba Customer Engineering

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

Super Contributor I

Re: new AP225 deployment with 802.1x on b/g

 

Our helpdesk has open tickets for several systems that are behaving this

way (dot1x auth succeeds, DHCP fails.)  this includes a Hon Hai adaptor with

the same OUI as your debug log (win8), and also a bunch of Apple branded cards

on OSX.  We just installed a bunch of 103Hs and a few 275s so we're hoping one of

those clients wanders over near those and we'll get to see if this is an AP-225

specific problem or not.

 

Out of interest, are all your Dell's using the same adaptors/drivers or do you have

a mixed bag of clients?

 

Contributor II

Re: new AP225 deployment with 802.1x on b/g

The two Dell's I've been having trouble with are the same model, E6430s I believe.  The two Macbooks I've have to go back and check on their versions/OS's.

 

I spent many more hours on this today.  The Mac's have been working fine since I enabled the 'a'-radios on the profile.  Ironically even though they aren't always connected to it.  The Dell's worked for a week (after setting the default channel to 36/80MHz) without a problem - but now refuse DHCP again (packet sniff seems to show a full EAP handshake and then nothing further, like it never asks for DHCP).  The building has thick walls and the clients tend to connect to 'g', even though they are 'n' capable.  I played around with trying to force them on 'n', even turing off the 2.4ghz range.  No go.  Even my Andriod stopped working at one point.  I turned the old 'open' SSID back on in the area so that I could connect; went to open a ticket, when magically the Dell's both started working again on .1x - same SSID, same VLAN, even the same frequency and channel they had been trying for hours.

 

When I went to leave I turned off the 'open' SSID in the area (which I wasn't using anyway), went to show the professor that they were working now (figuring something I had played with fixed it) - and neither would work.  I put the 'open' SSID back on those APs - as they were, but they wouldn't connect again.

 

If I roam to the adjacent building with the same virtual-ap/SSID but AP125/135s - they connect and get an IP right away.

 

Come to find out, the only other department complaining about our removal of the 'open' SSID also recently got upgraded to 225s.  I'm off tomorrow - but will most likely be opening a ticket Wed.

Contributor II

Re: new AP225 deployment with 802.1x on b/g

It looks like on the Instant side of things people are running into something similar.  DHCP with the AP 225 appears to be trouble.

 

DHCP-Timeouts-on-ARUBA-AP-225-on-Firmware-6-3-1-2-4

 

I'm going to try some of the suggestions from there.

Guru Elite

Re: new AP225 deployment with 802.1x on b/g


pgemme wrote:
(Aruba-M3-master) #show ap bss-table ap-name Bea-3-Rm334.32ca
Aruba AP BSS Table
------------------
bss ess port ip phy type ch/EIRP/max-EIRP cur-cl ap name in-t(s) tot-t mtu acl-state acl fm
--- --- ---- -- --- ---- ---------------- ------ ------- ------- ----- --- --------- --- --
18:64:72:03:2c:a1 HCWireless N/A 10.96.97.226 g ap 1/21/21 0 Bea-3-Rm334.32ca 0 1d:0h:18m:15s 1500 - 1 T
18:64:72:03:2c:a2 HCGuest N/A 10.96.97.226 g ap 1/21/21 0 Bea-3-Rm334.32ca 0 1d:0h:18m:15s 1500 - 74 T
18:64:72:03:2c:b1 HCWireless N/A 10.96.97.226 a-VHT ap 36E/21/21 0 Bea-3-Rm334.32ca 0 1d:19h:24m:12s 1500 - 1 T
18:64:72:03:2c:b2 HCGuest N/A 10.96.97.226 a-VHT ap 36E/21/21 0 Bea-3-Rm334.32ca 0 1d:19h:24m:12s 1500 - 74 T

(ArubaM3-1) #show ap bss-table ap-name Bea-4-Rm407a.6d84
------------------
bss ess port ip phy type ch/EIRP/max-EIRP cur-cl ap name in-t(s) tot-t mtu acl-state acl fm
--- --- ---- -- --- ---- ---------------- ------ ------- ------- ----- --- --------- --- --
18:64:72:f6:d8:41 HCWireless N/A 10.96.98.224 g ap 8/21/21 3 Bea-4-Rm407a.6d84 0 23h:32m:32s 1500 - 1 T
18:64:72:f6:d8:42 HCGuest N/A 10.96.98.224 g ap 8/21/21 1 Bea-4-Rm407a.6d84 0 23h:32m:32s 1500 - 77 T
18:64:72:f6:d8:51 HCWireless N/A 10.96.98.224 a-VHT ap 161E/22/22 0 Bea-4-Rm407a.6d84 0 23h:32m:32s 1500 - 1 T
18:64:72:f6:d8:52 HCGuest N/A 10.96.98.224 a-VHT ap 161E/22/22 0 Bea-4-Rm407a.6d84 0 23h:32m:32s 1500 - 77 T

Num APs:4
Num Associations:4

(ArubaM3-1)#show auth-tracebuf | include 18:64:72:f6:d8:41
Jul 30 09:04:08 station-up * 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 - - wpa2 aes
Jul 30 09:04:08 eap-id-req <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 1 5
Jul 30 09:04:08 eap-start -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 - -
Jul 30 09:04:08 eap-id-req <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 1 5
Jul 30 09:04:08 eap-id-resp -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 1 15 csilabwifi
Jul 30 09:04:08 rad-req -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 65477 212
Jul 30 09:04:08 eap-id-resp -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 1 15 csilabwifi
Jul 30 09:04:08 rad-resp <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41/10.108.193.106 65477 76
Jul 30 09:04:08 eap-req <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 2 6
Jul 30 09:04:10 eap-resp -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 2 105
Jul 30 09:04:10 rad-req -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41/10.108.193.106 92 332
Jul 30 09:04:10 rad-resp <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41/10.108.193.106 92 1112
Jul 30 09:04:10 eap-req <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 3 1034
Jul 30 09:04:10 eap-resp -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41 3 6
Jul 30 09:04:10 rad-req -> 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41/10.108.193.106 65535 233
Jul 30 09:04:10 rad-resp <- 1c:3e:84:af:5d:4f 18:64:72:f6:d8:41/10.108.193.106 65535 1108
...

(ArubaM3-1) #show ap active | include Bea
Bea-2-Rm214.6d0a Beaven 10.96.118.184 0 AP:11/21/21 0 AP:VHT:149E/22/22 225 Aa 1d:20h:22m:24s N/A
Bea-3-Rm321..6bc2 Beaven 10.96.106.209 1 AP:1/21/21 1 AP:VHT:36E/21/21 225 Aa 1d:20h:23m:57s N/A
Bea-2-Ha228.6c9c Beaven 10.96.104.213 0 AP:8/21/21 0 AP:VHT:149E/22/22 225 Aa 1d:20h:22m:12s N/A
Bea-4-Rm409b.6dbc Beaven 10.96.100.220 2 AP:11/21/21 1 AP:VHT:149E/21/22 225 Aa 1d:20h:23m:9s N/A
Bea-4-Rm407a.6d84 Beaven 10.96.98.224 2 AP:8/21/21 0 AP:VHT:161E/22/22 225 Aa 1d:20h:23m:10s N/A
Bea-3-Ha305.6ba0 Beaven 10.96.107.207 3 AP:1/21/21 1 AP:VHT:157E/21/22 225 Aa 1d:20h:22m:26s N/A

 Everything looks good on those from what I can see.  The APs are split across two controllers - but their outputs look similar. 

 

 


pegmme, is there any reason that you have b/g access points on channel 8, and all of your access points at full power?  Also, why are access points split across two controllers?  That could make troubleshooting harder.  Also, instant APs and controller-based APs do not use the same codebase.  There are plenty of people who are running with IAP225s and with AP225s and controllers, who do not have DHCP issues.

 

We need to narrow down the circumstances with your specific setup to determine what is going wrong.



Colin Joseph
Aruba Customer Engineering

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

Contributor II

Re: new AP225 deployment with 802.1x on b/g

I did setup a TAC case and we'll be looking into it much more tomorrow.

 

We have two controllers for 650+ APs, for the most part each building the APs are designated to a specific controller.  That building the APs are grouped differently, mostly left over from when we had to deal with licensing per controller.  If the local controller failed - license-wise we couldn't keep all the APs up - so for some important buildings we wanted to make sure at least some stayed up, and the only way was to split them up.

 

I'll check the power.  We have some profiles that up the minimum for the dorms and that building used to be a dorm.  Mostly because the APs were poorly wired down the hallways and would turn each other down rather than cover the corners of the buildings.

 

I brought over an HP today with Windows 8 and didn't have the DHCP problem - however I couldn't keep the support session open with Aruba support because every 10 minutes or so I'd be completely disconnected.  Oddly enough I'd click the SSID and get right back on. 

 

Hopefully by this time tomorrow I'll be able to post what we had configured wrong.  Our situation is we're rapidly replacing the 125s with 225s at the same time we sent a campus-wide  notification about the removal of the old open SSID.  The spots with the 225s are asking for the old APs back.

Super Contributor I

Re: new AP225 deployment with 802.1x on b/g

 

I finally got a user at our helpdesk that was willing to stick around long enough

to get a little debug going on one of these cannot-dhcp hosts.  We tried a few

of the easy tricks.  Walking him over by an AP-275 outdoor AP did not help him,

he didn't have drivers available newer than 2012, rebooting the APs he was on

didn't help either.  Turning off all the windows 802.11 bells and whistles like

PMK caching didn't do anything either, but I didn't expect it to because at a dot1x

level these users look just fine.

 

I had him on user-debug part of the time, so I'll sit down and clean up my

logs tonight and look that over, and if our 6.4.2.0 upgrade tonight doesn't

magically fix things, I'll send what I have in to TAC, not that I can get the user

back live again.

 

 

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