Honeywell 99ex models and MR52 AP

[Charlie]

I am converting from a Cisco based WLC to a Meraki infrastructure.  I am running into an issue with my Honeywell 99ex handheld scanners not being able to connect.   The SSID is using wpa2-enterprise, AES, PEAP-MSchapv2.  The SSIDs are about as exact as they can be with respect to securities and authentication servers.  

When on Cisco WLCs they connect just fine, when on Meraki they do not and RADIUS shows an error with the username.  

Did a packet capture and the Meraki "auth-exchange" shows the username field is blank, so that's why it's causing errors on RADIUS.  Kind of stuck between vendors here.  Honeywell says it works (like it does with Cisco WLC) plus using their latest firmware and Meraki of course does not see a username being transmitted and of course other devices can connect to the SSID just fine. 

Where do you all think the fix resides?  I am kind of leaning towards a Meraki fix since it does work with other vendors.  Any thoughts or direction?  

[PhilipDAth]

PEAP is a tunnel, and the actual username used for authentication is send inside of the PEAP tunnel.  There is a username field on the outside, but it is only used for tracking, and it is fine for this to be blank.

Because PEAP is a tunnel, the AP/WLC infrastructure does not see the authentication happening within it.  The AP/WLC simply passes it onto the RADIUS server.  The RADIUS server rips everything out of the tunnel, checks the credentials, and sends back an ACCEPT or REJECT.  The AP/WLC infrastructure then allows/blocks access based on this.

So if the RADIUS server (what RADIUS server are you using) is refusing the connection you need to look there.

The first thought that comes to my mind is have you added the Meraki APs in as clients to your RADIUS server?

The next thought is to check if the radius key being used on the Meraki APs matches the key defined for the client on the RADIUS server.

What specifically does the RADIUS server say is wrong?

If you use the option to test the WiFi authentication in the Meraki portal - does this work?

[Charlie]

The RADIUS only refuses connections with this client so not a shared key issue.  I can also get other clients to use the same SSID on the Meraki infrastructure.  So the back end radius seems fine.  **Added APs IP ranges and verified keys. 

The ISE server we are using reports this"

"Failure: 5400 Authentication failed

Reason: 22007 Username attribute is not present in the authentication request"

[PhilipDAth]

Have you checked the username/password programmed into the scanner works?

Perhaps its password has expired.  Perhaps the account has become locked out?

[PhilipDAth]

What firmware version are you using on your MR's?

[Charlie]

I'm sad and embarrassed to report that 10 handhelds are using the same username and password (we are fixing that!!) but in this case it helps because the ones still on Cisco WLCs using the same uname and password are working.    So prolly no lockout.

Also we are on version 25.11  - going to think about a 25.13 stable release tonight after the load slows down.  Might even consider latest beta after that. 

[Nash]

Will the scanners connect to a test SSID on the Meraki AP that uses WPA2-PSK? If not, will they connect to an open SSID?

Obviously, lock this SSID down so it does not have LAN access.

[Charlie]

yeah we tried with a lesser security - OPEN guest (and it does connect) but we do not have any PSK ssids at this location.  I'd have to spin one up to see if that can make a difference.  But kind of trying to stay away from PSKs for now so if it works I can use it for tshooting but would rather not like to share with the user.

[PhilipDAth]

Are you sure the older WLC environment is only using AES, as opposed to something older like TKIP?

Perhaps the clients are negotiating an older protocol that does not exist on the new Meraki environment?

Have you tried deleting the WiFi profile from a client and re-adding it, in case it is caching something?

[Nash]

Yeah no, definitely don't leave a testing SSID up for any longer than you're using it. 

Phillip may be onto something with regards to the older protocols. The Honeywells I've dealt with (CK75) are crotchety and the wifi NIC really doesn't support anything modernish. 

[Charlie]

Really appreciate the feedback @Nash and @PhilipDAth   Helps immensely.  As for the securities, they are as shown below.  No policies or splash pages or anything too terribly different from what I can tell.   Add yes all other devices can connect from the Cisco APs to the Merak APs.  Just seems like a interpretation between Mr52s and the supplicant on the handheld. 

Which does bring to mind.  Does Meraki have a testing lab or department like their big brother Cisco WBU to look at different device types for compatibility?   One that we can submit this model and code to have them run it thru their tests to see if the engineers see the same thing?  

Here's my MerakiCisco WLC

[PhilipDAth]

Could you tease me on the Meraki and trying setting WPA to WPA2 only?

I have a suspicion we are dealing with legacy protocol issue.

[Charlie]

I'm right there with ya.  I have tried to change that already - no luck.   Might take a packet capture from a Cisco AP that works and a Meraki AP to find the real root cause.  Might try and offload that task to Meraki support if they have the labs to get that done.  My sites are remote and I don't have an over the air packet sniffer handy for them to use locally. 

[PhilipDAth]

The MR's have a built in packet capture ….

https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Packet_Capture_Overv...

[PhilipDAth]

Another dumb question; there aren't any firmware upgrades for the Honeywell devices by chance?

[NolanHerring]

Are the Meraki access points sending the RADIUS frames from a subnet that you've allowed to accept them from on the RADIUS server? Not sure if your using NPS/ISE etc.

[Charlie]

Not an issue with RADIUS (using ISE).  Many other clients made the transition over from the Cisco platform just fine.  Just this one so far has been the thing putting the migration on hold.

[Charlie · Accepted solution]

Hey guys - Wanted to give you an update on the fix.    Honeywell - Dolphin 99ex.

Turns out the application analyst had what they thought was an updated version of code but did not take in account any service pack releases.  They reported 26.7  but did not include the latest service pack.  Anyways... long story short.  They upgraded to this release below with updated WLAN driver dated 3/12/2019. Thanks for the sounding board and feedback.

IPSM_BT_WLAN.zip

Updated on 20190312:

* Replaced Service Pack SP26_07_03.CAB with SP_26_07_07.CAB
* Replaced WLAN driver WLAN_D99EX_25.CAB with WLAN_D99EX_27.CAB

[Charlie]

Looking but they tell me they have the latest.  fwiw- kernal 26.07

[Asavoy]

@Charlie I would advise against using the 26.3 Beta firmware with the MR52. Now that staff is starting to return (school district) I discovered a bug where devices on the 2.4ghz band (printer in this case) would Disassociate:Reason Unknown after a minute or two of connection and would not reconnect unless the WAP was reset and then it would just repeat the issue a minute or two later.

[NolanHerring]

---

@Asavoy wrote:

@Charlie I would advise against using the 26.3 Beta firmware with the MR52. Now that staff is starting to return (school district) I discovered a bug where devices on the 2.4ghz band (printer in this case) would Disassociate:Reason Unknown after a minute or two of connection and would not reconnect unless the WAP was reset and then it would just repeat the issue a minute or two later.

---

Yikes!

Assuming this can be verified with different devices (maybe just make a 2.4GHz only SSID to test). Is this just you testing on your own or did you have Support verify and open up a case? Curious to know if they have any fix for this as well please and thank you.

[Asavoy]

@NolanHerring This was just me testing on my own. I've run into a bug that I worked with support on previously which pertained to the MR34 and WPA2 DHCP rejection. I had to roll back to 25.13 because teachers are starting to report and I have quite a few Brother wireless printers at the site that has the MR52s. Zero connection issue with the 25.13 firmware.

Basically, I reset the network interface on the printer and started fresh. It connected and would accept a print job. I could see it on the WAP in the dashboard. Then it would drop from the WAP with a Reason Unknown message, but the printer itself would have a solid wi-fi light. I could reset the WAP, watch the printer connect to the WAP next door, and then repeat the process of dropping with Reason Unknown. The printer has the latest firmware from Brother and is less than a year old. It's a model I have a few of at multiple sites and haven't had an issue with it previously.

I started a case with support just to inform them of the bug. Unfortunately I don't have the ability to test this one any further!

[NolanHerring]

Thanks for opening the case. The more people that do that, the better the firmware will be for everyone 😃

[Charlie]

thanks @Asavoy .  But to be clear I did not use beta code on my MR52s.  I used stable release code on thr MR52s. - the 26 train that I mentioned is actually the firmware for the handheld device.   But as with most beta versions, an abundance of caution is always a good idea and I'll stay away from this one for now cause I am in healthcare and we are still using plenty of 2.4 devices.