A few years back the wireless team at UiT elected to make our eduroam service 5GHz only. The rationale was a cost/benefit assessment – the benefit of three extra 20MHz channels to carry traffic wasn’t worth the effort of providing them. Especially in student villages, where legacy rogue APs and uncontrollable interference sources abound. Added complexity in troubleshooting was another card on the table.
We decided that we would offer an inferior eduroam service for the benefit of 2.4GHz-only equipment, on a separate SSID, but sharing resources with “the real eduroam” on the wired side (VLANs and IP address space). But unfortunately, techies as we are, we picked a neutral and technologically oriented name for the SSID: eduroam-2.4GHz. A name that probably created no associations whatsoever with our wifi byod users. In retrospect we should have picked something that sounded like the smell of fish rotting in the sun!
The consequence of our unlucky choice was that many users with dual-radio devices configured profiles for both eduroam and eduroam-2.4GHz, probably to improve the odds of finding a network to connect to. And we were no better off than if we’d just established the eduroam SSID on both bands in the first place.
Fast forward to the present:
This fall Apple introduced private MAC addresses in their operating systems. Each SSID that the device connects to is presented a unique MAC address. From the perspective of the wifi infrastructure, these addresses are used to identify and communicate with the devices. If a device presents two MAC addresses, then it’s considered to be two different devices as far as “the wifi” is concerned. And each MAC address is given a separate IP address. Which means that whenever the device roams between our two eduroam SSIDs, the active applications on the device have their operational IP address changed.
Many applications can cope with that. If your web browser fetches a page with one IP address, and the next page with another, that’s usually fine. But if your AV streaming application has it’s IP address changed beneath it’s networking interface, then it’s going to fall. Hard.
The timinig couldn’t be worse. Corona has brought a proliferation of digital meetings and distance lectures. Any student with both eduroams configured on their laptop risks five-minute unscheduled transmission breaks in knowledge transfer from their professor. And Murphy will ensure that those five minutes will be the most exam relevant of the semester.
Now we’re in the process of changing the name of our “inferior” eduroam on the 2.4GHz band, to something that our users will hesitate to select. Being an academic institution we couldn’t make it like fish rotting in the sun. It’s going to be lowQualityUnstable-eduroam.
(Before writing this, I searched for similar experiences or descriptions. The closest I found was this piece of advice: “Also, consider the impact of a per-SSID randomized MAC if corporate IT devices connect to more than one SSID” in https://www.extremenetworks.com/extreme-networks-blog/wi-fi-mac-randomization-privacy-and-collateral-damage/)