Wireless Access

I have random clients, mostly Android devices, that will not seem to get an IP address when connecting to the staff wireless. I checked the station table and I can see they make it past the logon role and are assigned the proper role.

 

I can see the DHCP discover come into the server however I never see a DHCP request. If I move this same client over to the WPA2 or Open wireless, it gets an IP immediately. All 3 SSID's utilize the same VLAN (during this testing anyway) and same DHCP server (Windows Server). Other devices get IPs fine some days and not other days it seems.

 

Appreciate any ideas. This is an Aruba system with 215's (not IAP) and RADIUS.

check the show auth-tracebuf for this user and make sure it looks OK, but, I would move onto doing a packet capture for this user, first in datapath then next in the AP itself.

 

steps...

1. disconnect the user

2. connect a laptop or server with wireshark on it "somewhere" in the management network, just as long as it can reach the controller. Note the IP address of the laptop (since this is not a high rate test, you can be wireless if needs be, just be aware of any firewall acls in the wireless network)

3. Ensure the laptop firewall is disabled !

4. enter the following in the controller CLI

    packet-capture destination ip-address 1.2.3.4   (laptop IP)

    packet-capture datapath mac <the mac address> all

5. connect the user, you should see packets arriving in wireshark within seconds of connecting. If you don't see "note1" below.

6. stop the capture using "packet-capture datapath mac <the mac address>"

 

Note1: If you see nothing, then test it with a working connected mac address, start the capture and ping the user, you should see packets in wireshark. If not, you probably have a firewall in between causing grief.

 

With the above you may get a clue whats going on, the capture is serial, e.g. when you see the dhcp offer (presumably) coming in from the server, the very next packet should be the encrypted packet heading to the AP. Peer into that DHCP offer and make sure it looks exactly as expected and is coming from the expected DHCP server etc.

 

This won't rule out RF issues, but will at least confirm that your DHCP actually offered the IP and the controller sent it to the AP.

 

If all looks well, then time to consider diving into an AP capture. Note that the AP will now try to send packets to the wireshark laptop, nominally using udp/5555, so make sure that a) your AP subnet can reach the wireshark laptop and b) that there is no firewall in the way.

 

see http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-to-do-the-Air-packet-capture-on-AP-from-the-Command-Line/tac-p/311129 for how to do that. It will be harder to diagnose from that as all the packets are encrypted, but with some filtering on the mac address of the cilent you should be able to follow the dot1x connection and the subsequent attempt to get an IP via DHCP based on the sequence of packets.

 

 

 

 

Alrighty...so I'm only seeing the DHCP Discover packets coming through and no Offer, Request or ACK.

 

What is odd though, is this literally seems to be cell phones only. Windows devices appear to be fine. I've attached the auth tracebuf output, which looks comparable to any other device that is working.

 

I've kept the packet capture running on wireshark, watching the bootp packets. EVENTUALLY it will get one. I'm also packet capturing on the DHCP server's end and can see the packet being sent back to the Aruba controller (the Offer), but it is just not making it. I'm a bit puzzled as to what to do next. I don't have any firewalls between the two that I'm aware of.

 

The only "pattern" I think I've found to this is that if I turn off the wifi on the phone for about 15-20 minutes, and reconnect it, it seems to go OK, but there really isn't a pattern. Sometimes it just "goes" - I just don't know what. I've had it running for 30 minutes now, and of course it hasn't gotten an IP so I cant see it go through.

 

So then I took a capture of everything that was working (a windows device) and have included that. Just not sure what the difference is, as they are both just requesting an IP...

FINALLY, it got an IP and I have the packet capture - it is attached.

hi Marcus,

It appears switch 98:f2:b3:90:2d:00 is acting as DHCP relay (10.5.24.1) - was it involved in all your tests as well (e.g. open, psk) ?

 

There are some small differences in the two captures, perhaps related to this relay. Consider these packet #s from "working cap", where the client is requesting "broadcast dhcp" which is a very windows thing to do and may be the reason for the slightly different behaviour between the devices.

 

574 - broadcast discover on wifi

577 - broadcast discover packet flooded to sniffer vlan

578 - broadcast offer packet flooded to sniffer vlan, relay=10.5.24.1, dhcp server 10.0.10.21

579 - broadcast offer packet converted and unicasted to client on wifi

584 - broadcast dhcp request from client

587 - broadcast dhcp request flooded to sniffer vlan

588 - broadcast ACK from server flooded to sniffer vlan

589 - broadcast ACK converted and unicast to client on wifi

 

Now consider the single working cast of "capture", where the client is requesting 'unicast' dhcp.

 

11009 - broadcast discover from client

11010 - broadcast discover flooded to sniffer vlan

11011 - unicast offer from server, relay=10.5.24.1, dhcp server 10.0.10.21. Note that this time, the offer is only seen at the controller, arriving via vlan 524 over a trunk port

11014 - broadcast dhcp request from client

11015 - broadcast request flooded to sniffer vlan

11016 - unicast DHCP ack from server received on vlan 524 and unicast to client.

 

So where does this leave us.... It would appear the working/not working cast when the client is not setting the bcast flag on the dhcp packet is due to either the controller or the relay - seems to be one of those two. Without necessarily resorting to doing a packet capture on the trunk port, I would suggest to focus on eliminating the relay as it's the easiest thing to do. 

 

Would it be possible to try adding an ip helper for 10.0.10.21 on the controller as a test to cut 10.5.24.1 out of the equation?

 

another small difference that I noted is that the working capture has no 802.1q headers inside the vlan 524 traffic, where as the not working one always does - or at least for the clients. If the captures were  both made the same way I am not sure why there would be a difference, unless maybe something like a link agg where one link has a wrong native vlan set.

 

Thanks for the assistanace on this. These captures were done identically, so it is definitely interested that there is 802.1q traffic on one and not the other. Some information:

 

Capture done on: Win 10 PC (hardwired) onto VLAN 524

Devices:

Surface Pro - VLAN 524

Pixel XL - VLAN 524

 

There is no link agg at all. There is a 10GB DAC connecting the Aruba Controller to our 5412 chassis.

 

Aruba Config:
Port Mode - Trunk

Native VLAN - 1

Allow VLANS - 1,216,224,316,324,416,424,516,524,616,624,716,724,816,824

 

Switch Config:

tagged vlan - 216,224,316,324,416,424,516,524,532,616,624,716,724,816,824
untagged vlan - 1

 

No port errors at all.

 

When I test the Surface Pro on any of the wireless networks (therefore any vlan), it immediately grabs. When I test the pixel, it will grab an IP immediately from anything not 802.1x (any vlans ending in 16). All the X24 vlans are 802.1x. On the switch, there is no difference in setup - same on the Aruba controller.

 

On this most recent capture, I removed the DHCP helper from the vlan 524 on the switch and had it only in the controller. The Windows device immediately got an IP and the phone is still awaiting an IP as I'm typing all of this. I'm let the capture run for a while before attaching it to this after the phone finally got an IP. This was a realtime test:
Started Captures, Shut off Wireless on phone, and turned it back on. Released IP on surface, and requested a new. I then shut off the capture after a minute or so on the Surface device (to hopefully cut down on size). Unfortunately it still is a large file, but I've linked to it here since its bigger than the max upload size: https://owncloud.overwatchdata.com/index.php/s/JomV4Ew2BzvcXLP - the link does expire on 11/18/2017.

 

Unfortunately you can see other devices doing the same thing (all phones/non-widnows devices it seems). The mac addresses to check out are the same as before:
Pixel: 10:f1:f2:83:56:59
Surface: c4:9d:ed:01:0f:b3

 

Thanks again!

hi Marcus, the DL link doesnt work - can you re-put it (DM me the link if you want).

 

Noted w.r.t. the setup, port channel and your latest test, couple of questions....

a) in the non dot1x case, is the relay all setup the same way ?

b) can you share a tar logs techsupport (DM the link) ?

c) can you try a test - create a test ssid, test virtual ap, set it to use dot1x, but the vlan ID on the vap profile to be one of the non dot1x vlans. Use the CLI clone command to speed it up, e.g.

 

conf t
wlan ssid-profile test 
  clone dot1x_ssid_profile_name
  essid testing
!
wlan virtual-ap test 
  clone dot1x_vap_name
  ssid-profile test
  vlan XXX
!
ap-name some_test_ap_name
  virtual-ap test
!

 

OK, I finally have a resolution. It looks like somehow, with the ACL in place, it worked some of the time - but not all of the time. It appears with the latest 6.5.1.9 update it changed something/corrupted the ACL. I deleted and recreated the ACL and everything is working.

 

I thought this was odd because I changed all the roles to authenticated (which is everything open) and it didn't seem to matter. In doing everything, I recreated the SSID/VAP Profile and its all working now. It seemed to really just affect the DHCP for some reason - it is just odd that it worked some of the time and not others.

very strange - can you show what the ACL looked like that you had applied ?

Will you please tell me what was the solution and what we need to do for resolve, I am also facing this issue , but when restart it solved.