Migrating to Juniper Mist Wi-Fi while the legacy Wi-FI is still in production
Recently, one of our customers has chosen for Juniper Mist to replace their +1000 legacy APs across different sites. The customer is a very strong believer in Bluetooth Low Energy (BLE) technology. Thus Mist was the perfect match. As a leader in the asset tracking space with their patented 16 antenna vBLE array, ease of integration and use with other platforms.
While starting the migration, we had to make sure that we didn’t disturb the production legacy network. Thus we opted to migrate department by department, resulting in some overlapping areas between Mist and the existing Wi-Fi infrastructure. While starting our tests with a couple of Mist APs with the same production Service Set Identifier SSIDs. We started running into some troubles with the ASCOM Wi-Fi phones.
Beforehand they were working completely normally on the test SSID. We saw that these phones couldn’t stay connected to the Mist APs once the SSID was renamed to match the legacy AP.
What went Wrong?
As a wireless engineer, my first thought was that something was not compatible between the wireless protocols enabled on Mist and the Ascom phones. So we started our favorite part of the job: taking and analyzing layer 1 RF captures, which for the record is very easy to do in Mist across the whole site. While doing so. We realized that the phone got de-authenticated on layer 1 quickly after completing it’s 802.11 authentication with the Mist AP.
In the captures, the Mist AP had no reason to de-authenticate the client, as the Phase Shift Keying (PSK) was accepted and the client got authorized. Thus indicating that the de-authentication was a result of the client suddenly leaving the Basic Service Set (BSS) without announcing this. That led us to another discovery: once the clients connected with the Mist APs. They couldn’t connect anymore on the legacy APs. Interesting!
What was the Outcome?
Looking into the legacy controller, we saw that these clients were flagged because of connecting to a Rogue and Honeypot AP. Aha! Now we had to figure out how to solve this behavior. After digging into the documentation and settings. We found several protection mechanisms that are mostly enabled by default on the legacy infrastructure, de-authenticating clients on 3rd party APs and denying them access once they try to reconnect to old Wi-Fi.
We have learned a lot of valuable lessons. Not only on the legacy Wi-Fi side of things and their protection mechanisms, this also confirmed something we already knew:
mixing two different wireless vendors is never a good idea, and this case proved us why.
1) Not only will the roaming performance be affected between two vendors.
2) It can result in a lot of headaches in production and weird behaviors on the client’s side.
Author: Soulaiman Alhouari