Wireless Access

Hi everybody,

 

We are just in a migration process where we switch from Juniper to Aruba. We are not able to switch all APs at the same time so we have to make it step by step....

So we have Juniper APs and Aruba APs in one buliding.

Unfortunately we have some problems when Motorola MC9200 Clients move between these different infrastructures.

 

Vlan is bound to the SSID on both systems.

Vlans are the same.

 

Scenario 1:

1. Motorola Client connects with Juniper AP

2. Motorola Client moves from Juniper AP to Aruba AP -->Client connects but no IP-Adresss

 

Scenario 2:

1. Reboot Motorola Client and connecting with Aruba AP -->no problem

2. After initial connection with Aruba AP, Motorola Client moves to Juniper AP -->no problem

3. Motorola Client moves again from Juniper AP to Aruba AP -->Client connects but no IP-Adresss

 

At the moment we have no idea whats going on?

 

Do you have any ideas?

1. Do you have "Enforce DHCP" defined in the triple AAA profile for that SSID? 2. Do you know what driver version the MC9200 scanner is running? We were in a similar situation couple years ago and the original factory driver was highly unstable - didn't like moving between Meru to Aruba - even while staying on an Aruba - the adapter would eventually crash to point it couldn't be seen without a reboot. We updated the driver and that solved several issues including support for SHA-2 certificates.


#AirheadsMobile

No, we didn't activat the DHCP enforce option because we also have clients which use static ip's.

 

The driver of the Wifi Adapter is:

Driver: X_2.03.0.0.17

Firmware: X_2.03.0.0.17

 

 

RR86,

 

I would try enabling "FDB Update on Assoc" in the Virtual AP profile on the Aruba Controller , which updates the wired bridge table when a client associates.  It is possible that the client does not do a gratuitous ARP when it roams between infrastructures.  http://www.arubanetworks.com/techdocs/ArubaOS_65x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/1CommandList/wlan_virtual_ap.htm?Highlight=FDB Update on Assoc

 

I have no idea if this will even work, but it might be worth a try...

 

 

Just tried it. Unfortunately same problem...

 

@RR86 wrote:

No, we didn't activat the DHCP enforce option because we also have clients which use static ip's.

 

The driver of the Wifi Adapter is:

Driver: X_2.03.0.0.17

Firmware: X_2.03.0.0.17

 

 

---

Ah, it was the MC9090 and MC75A scanners that I worked on. They were several driver versions behind on the Fusion Driver when they came to us. Looks like there is an update available - X_2.03.0.0.018R (Release notes mention a couple roaming fixes) - https://www.zebra.com/us/en/support-downloads/software/utilities/fusion.html - You might have some luck with their tech support. When we switched to SHA-2 and wanted to validate certificates - I gathered a packet capture, shared with support, and then had me run a "Jedi" diagnostic tool. Shortly after they provided a driver version (40R) that supported SHA-2.

 

You mention it would "Connect" just with no IP-Address. Wasn't sure if meant from the client side perspective or controller. I was just curious if when the Motorola 9200 roams between Juniper and Aruba - does it complete the full authentication/hand-shake process and enter into the Aruba User-Table?

 

Hi,
Thanks for driver information!
I will check if we can upgrade.

From the Client side it looks like it is connected.
I think it is also in the user table but I'll check it tomorrow.

Just made a packet trace with: packet-capture datapath mac [MAC] decrypted

 

Last entry is a successful certificate exchange (we use eap-tls). See attached file...

 

It seems that there is no DHCP ACK...

 

show log network all | include [MAC]

shows no DHCP ACK...

 

ep 22 12:46:13 :202541:  <4060> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, Flags 0x42, Opcode 0x5a, Vlan 2216, Ingress pc0, Egress vlan 2216, SMAC 40:83:de:b2:0d:64
Sep 22 12:46:13 :202534:  <4060> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan2216: DISCOVER 40:83:de:b2:0d:64 Transaction ID:0xa3cdcffd Options 3d:014083deb20d64 37:0103060f2c2e2f4243
Sep 22 12:46:15 :202541:  <4060> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, Flags 0x42, Opcode 0x5a, Vlan 2216, Ingress pc0, Egress vlan 2216, SMAC 40:83:de:b2:0d:64
Sep 22 12:46:15 :202536:  <4060> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan216: REQUEST 40:83:de:b2:0d:64 Transaction ID:0xa3cdcffd reqIP=192.168.5.10 Options 3d:014083deb20d64 37:0103060f2c2e2f4243

 

---

@RR86 wrote:

It seems that there is no DHCP ACK...

 

show log network all | include [MAC]

shows no DHCP ACK...

 

ep 22 12:46:13 :202541:  <4060> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, Flags 0x42, Opcode 0x5a, Vlan 2216, Ingress pc0, Egress vlan 2216, SMAC 40:83:de:b2:0d:64
Sep 22 12:46:13 :202534:  <4060> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan2216: DISCOVER 40:83:de:b2:0d:64 Transaction ID:0xa3cdcffd Options 3d:014083deb20d64 37:0103060f2c2e2f4243
Sep 22 12:46:15 :202541:  <4060> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, Flags 0x42, Opcode 0x5a, Vlan 2216, Ingress pc0, Egress vlan 2216, SMAC 40:83:de:b2:0d:64
Sep 22 12:46:15 :202536:  <4060> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan216: REQUEST 40:83:de:b2:0d:64 Transaction ID:0xa3cdcffd reqIP=192.168.5.10 Options 3d:014083deb20d64 37:0103060f2c2e2f4243

 

Something I noticed in the Request - "vlan216" but the other dhcp activity shows "vlan2216". Not sure if that was normal for your environment/configuration/etc and my experience with DHCP is limited on server-side. Just an observation I noticed.

 

Went onsite with TAC yesterday.

We noted that the frames sent by the client are WMM QOS, whereas the client was associating 11g since HT is disabled on both the Juniper and the Aruba systems.

(p12mc0004) #show ap association | inc 0d:64
p12ap1008  40:e3:d6:b5:06:81  40:83:de:b2:0d:64  y     y      1    3      production  216      0x1003a    g               1m:39s       1          A      0/0                     g-HT-20sgi-1ss


show datapath station | include 40:83:DE:B2:0D:64^M
40:83:DE:B2:0D:64 40:E3:D6:B5:06:81  216           50            0    0000 0001      216          0 0000/0000/0000/0000   32  AR



+----+------+-----------------------------------------------------+
|SUM/|      |                                   |                 |
|CPU | Addr | Description                                   Value |
+----+------+-----------------------------------------------------+
|    | [00] | Crypto Requests Total                         74219 |
|    | [02] | Crypto Response received                      74219 |
|    | [82] | AESCCM Decryption Failures                      430 |
|    | [89] | AESCCM Encryption Station Not Ready              22 |
|    | [97] | AESCCM Decryption Station Not Ready               3 |
|    | [100] | AESCCM Decryption Invalid QOS Frame             427 | <-----------------------These counts correspond

By enabling the WMM flag in the wlan ssid profile, the SSID where HT is disabled now allows the WMM frames from this client which is trying to use 11n/WMM whereby the SSID doesnot hae HT enabled.

note - we also changed the Virtual AP in question to have a default VLAN of 216

What is not clear is why the device worked when connecting fresh to the Aruba AP, but this situation happened when the device roamed from the 11g Juniper to the 11g Aruba - note the client was sending WMM/QOS frames to the juniper fine.  I can only surmise the client continued using WMM/QOS data frames because it saw the roam to the Aruba as a "re-association" as we see in the packet captures.