New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Untriaged
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature

Sign in to add a comment

FR: Support for more hidden SSIDs than the hardware supports

Project Member Reported by, Jan 15 2016 Back to list

Issue 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.

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

Comment 1 by, 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.

Comment 2 by, Jan 18 2016

Labels: Cr-Privacy

Comment 3 by, Jan 19 2016

Assigning feature request to PM for prioritization.

Comment 4 by, Jan 20 2016


Comment 5 by, Apr 29 2016

212 KB Download
Labels: -enterprise-hotlist Enterprise-Hotlist

Comment 7 by, Oct 28 2016

Labels: -Enterprise-Hotlist Hotlist-Enterprise
Please use Hotlist-Enterprise, not Enterprise-Hotlist.
117 KB Download
4 bytes Download
Project Member

Comment 9 by, Aug 18 2017

Labels: Hotlist-Recharge-BouncingOwner
Owner: ----
The assigned owner "" is not able to receive e-mails, please re-triage.

For more details visit - Your friendly Sheriffbot

Sign in to add a comment