FR: Support for more hidden SSIDs than the hardware supports
|Project Member Reported by firstname.lastname@example.org, Jan 15 2016||Back to list|
Description: Some chipset limitations on number of hidden SSIDs scanned for makes impossible to auto-connect to many of the managed wifi networks on the device. Use case: A customer has 6-10 managed hidden SSID networks on their Pixel Chromebooks. There is a chipset upper limit of 4 SSIDs for a single scan on Pixel. Therefore this Pixel Chromebook is not going to connect to all the managed wifi networks automatically. Motivation: Admins can configure numerous managed hidden SSID wifi networks in CPanel, they would incorrectly assume that this would mean all hidden managed networks will be connected to. The number of hidden SSIDs that the device will actually connect to is dependent on the which device is being used, making the expectation across a fleet of chromebooks unpredictable. Existing workarounds: Don't have more managed hidden SSID networks than the device chipset can support. This can be found via: $ iw phy | grep -i ssid max # scan SSIDs: 4
Jan 15 2016,
Actually the work-around is "have less hidden SSID networks (managed + unmanaged) than the device chipset can support". In the example case where we have 4 SSIDs supported by the chipset, we need 1 slot to do the "broadcast scan" for non-hidden SSIDs, leaving 3 remaining slots for hidden APs. Possible solutions: - Somehow implement / mandate firmware changes for all chipsets to raise this to some arbitrarily higher maximum: + Each added SSID lengthens the scan time making performance worse and worse + This has a multiplicative effect on over-the-air congestion + Leads to added instability in a part of the firmware we know has been very tricky in the past. - Perform multiple scans, rotating in a different subset of hidden APs + Do we wait for all scans to complete before deciding where to connect? * If so, this has an even bigger latency penalty (3-5 seconds per scan) * If not, we stand to choose a sub-optimal AP with incomplete informtaion + Need to build a complex and brittle state machine to sequence scans + Significantly higher network congestion and power consumption due to iteration over channels multiple times - Wait for a re-architected solution + An implementation that took context / location into account would have several advantages: * We'd scan first / only for APs we expected to be available leading to faster opportunistic connections causing less congestion. * Use MAC randomization to help address some of the nasty privacy concerns that come along with hidden SSIDs. My take is we wait for a better solution than the hacks available to us now, and at the same time hope that folks on the infrastructure side realize that hidden SSIDs offer negative added value for privacy and security.
Jan 18 2016,
Jan 19 2016,
Assigning feature request to PM for prioritization.
Jan 20 2016,
Apr 29 2016,
Aug 6 2016,
Oct 28 2016,
Please use Hotlist-Enterprise, not Enterprise-Hotlist.
Jul 11 2017,
Aug 18 2017,
The assigned owner "email@example.com" is not able to receive e-mails, please re-triage. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sign in to add a comment