My Aruba setup -
4 - AP505 access points running 10.4.0.1_86647
Three SSID's broadcasting, one SSID is using cloudauth with Azure AD.
My Symptoms/issues -
When the client tries to associate the Aruba AP both in the logs and in central reports:
AP and Client ESSID do not Match
And of course, the client cannot connect. I've done some pcaps, and from what I can tell the Client is sending the SSID without issue and it matches.
I have reached out to Aruba support already and they deflected as fast as they could to the network adapter company, which makes sense. But they said nothing has been reported on their end. I have a bunch of laptops that use this Wi-Fi adapter, which is the AMD adapter of choice through a joint AMD/MediaTek partnership. This adapter is known to have spotty roaming and other issues as found in other communities like Reddit. I have tried many different things from upgrading the adapter drivers, using old drivers using ones in-between. Turning off 802.11ax, then 802.11ac and then chilling on 802.11n. Disabling roaming on the adapter itself and doing other basic known tweaks to see if I could get this to work. Alas nothing really works beyond plugging in USB wi-fi adapters with a Realtek chip. I have tried working with the laptop manufacturer to see if they could replace the units with either the intel or Qualcomm adapters that they also list drivers for. I'm assuming they are building these systems with whatever supply is available as the spec sheets and builds only list "WI-FI 6E Wireless adapter" vs something more specific. The adapter is also embedded otherwise i'd just buy new adapters and swap them out. Anyways, working with the laptop maker is also an uphill battle and since it's any laptop in my environment that has this wi-fi adapter, I am thinking it was either a recent Windows Update or something else that broke things. The laptops worked with some old 802.11ac Meraki access points before. But when I switched to Aruba AP505 units it seemed like things just went downhill at the same time. I cannot find an event beyond when I swapped AP's in my environment that caused all of this. Nothing from client logs indicates issues beyond not being able to associate.
As time went on the users found that on some networks, they were fine, other networks they couldn't connect. For example, one person said their home wi-fi used to be fine but now when they go home, they must reboot their computer every morning to connect to wi-fi. At home they are using an Xfinity XB7 which has a Broadcom radio in it. We did find that sometimes disabling/enabling the adapter could make it connect and work. Or rebooting could make it work. But other times it just flat out refused. I tried creating a new WLAN with a basic name of test and no psk or auth and all advanced things turned off and beacons set to default and still it refused to connect with the same "AP and Client ESSID do not Match" error. It's just odd this wasn't a thing when we had Meraki and only seemed to pop up on our migration to cloudauth with the Aruba AP's. I did also try removing the Aruba onboard tool and that had no impact on the results.
Has anyone seen this type of behavior before? If you check your central portals for failed clients, do you see any client with the hardware name of "CLOUD NETWORK TECHNOLOGY SINGAPORE PTE. LTD." that is failing for "AP and Client ESSID do not Match"
Thanks for any advice that you have.
I finally got time to sit down and figure this out as support wasn't of help. The issue with this is around hotspot 2.0/passpoint. The Aruba Onboard profile that gets pushed has the following:Because of this, when the client that has this type of MediaTek adapter it causes the unit to get stuck in a permanent state of trying to connect to that SSID and failing. When you reboot the system and log back in, it auto tries to connect causing it to get stuck. And with the quick resume feature of Windows that is extremly buggy, this can make it appear where the WLAN adapter is just broken until you unload the wireless profile from the device. The workaround is to export the Aruba wireless profile with netsh. Then delete the profile with netsh. This allows Aruba Onboard to stay linked to the user certificates for updates. You then modify the exported profile xml, remove the Hotspot2 stuff from the xml file. Then manually readd the profile with netsh and apply it to the user profile. If the computer was already in a failed state, you will need to reboot once for it to work. But if the adapter hasn't attempted connecting yet then it should just work.
I do have a case open still, since June with Aruba and recently updated the case with my findings. I did request what the purpose is from the developers view as I can only theorize why Aruba Onboard forces passpoint like it does, and yet it still works just fine. Which is per the spec looking at Microsoft docs on passpoint as they point out passpoint wasn't officially supported in windows 8/8.1 and yet it has all the pieces to make it work, so depending on how the profile is delivered it will work on windows 8/8.1. Which I think my manual change put it in that mode. Now the question is who's bug is it. Mediatek, Windows or Aruba. Since all my non Mediatek stuff works I am thinking Mediatek. Hopefully this helps anyone else that may find themselves with this issue.
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.