Wireless Access

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

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.

(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. 

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

---

@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.

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.

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?

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.

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.

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.

We're still trying to narrow this down.  TAC thinks only this specific model/driver/OS combination is the problem and a one-off.  That may be true - but our students have lots of these models and our current workaround will be to put the AP-70s back in the buildings.

I was able to eliminate ClearPass Auth from the equation - as well as a VLAN pool.  We sniffed 1 vlan with a new SSID and watched the DHCP discover packet leave the client - but it never gets to the network.  The packet must be getting dropped at the AP itself?

I'm experiencing a similar issue. I have different Virtual AP's configured, one uses 802.1x to auth against clear pass, the other lands the user directly on one of the vlans assigned via the role. DHCP behaves just fine and dandy without .1x, but the .1x authenticated clients never have their dhcp discovers transmitted to the dhcp server. I've attempted this both with a DHCP relay agent to ISC DHCPD and with the internal DHCP server on the controller. Issues occur with an iPhone, macbook pro, and a windows laptop.  Have primarily experienced problems with AP-225, but will try moving some 135's into that AP Group to see if the behavior persists.

No apparent change while connecting via AP-135

We've got someone at TAC working on looking over our similar-sounding case.

If you've not quite got to the point of filing a TAC case yet (it can be hard to find a sample system that doesn't come attached to a user that needs it :-), the first thing TAC is probably going to want you to do is enable DHCP debugging, so if you've already been in a situation where you've enabled heavy debugging and know your syslog/controllers can handle it, you might want to consider doing that preemptively:

logging level debugging network process dhcpd

logging level debugging network subcat dhcp

...this seems to generate some output even when your DHCP servers are external, so "dhcpd" seems to lump in the passve inspection.

In our case it seems no debug output is generated for the systems exhibiting the problem.

Just worked through it with TAC, total noob mistake: forgot to put an appropriate ACL on the user roles being specified in CPPM.

Popped on allowall acl on all of them and we're good.

Not the same problem then.  Glad to hear you are working, though.

Finally got everything worked out.

Support was great and we finally were able to narrow it down to the '802.11 radio profile' - specifically seems to be having 'High-throughput' enabled on the 'g' band.  Crazy enough if we roll the settings back it will continue to work; until a reboot/reload and it will stop working again.

If anyone runs into this similar issue I'd definitely recommand creating a new dot11g/a-radio-profile (even if it has virtually the same settings) and applying it.

If I were to try to begin to guess why this happens with the AP225/non-open SSID on a specific model Dell (Latitude E6430s) - perhaps it has something to do with Dell calling it an 'n' Broadcom network adapter - but if you dig deep it seems to only be able to do 'g'.