Question regarding BSSID table and hidden SSID

Daniel Lapointe dan.lapointe
Thu Dec 12 08:11:11 PST 2013

* Background:  We are operating in an environment with multiple access
points utilizing WPA2/EAP and hidden SSIDs.  Corporate policy dictates that
we use the hidden SSIDs even though there is no security benefit in doing
so. Obeserved behavior / Issues:  Our laptops do not roam between APs
reliably.  When using the WPA_CLI interface to view the BSSID table and
scan results, we see two values for each of our APs.  One BSSID value from
the Beacons that has no SSID associated to it and a second BSSID value from
our Probe Requests that does have the correct SSID listed.  Once we make
the initial association to an access point, the value in the table from the
probe request is never updated again because no scanning occurs for a
channel on which we are already associated.  The table values for that AP
only get updated on the one with the hidden SSIDS and other neighboring
channels, presumbably from the Beacons.  The problem arises when we try to
roam to another AP.  Here is a sample scenario:  We initially associate to
an AP with a signal strength of -65.  This value is stored in the BSSID
table with our SSID, but it never gets updated again (because no more probe
requests occur on the channel to which we are currently associated).  As we
start to move away from this AP toward another one our signal strength is
decreasing (noticeable by using signal_poll within the WPA_CLI) but the
scan_results table is not updated.  So, the logic utilized for determining
when to switch APs is looking for a difference of > 5dB.  Unfortunately,
since the table has an incorrect (old) value for the current AP no decision
to roam is ever made based on the incorrect values.  As we get futher away
from the AP our signal becomes weaker and perfomance suffers drastically
until we completely lose the signal and a new association is finally
triggered.  It appears as though the value for our BSSID with the NULL SSID
does in fact get updated, but since we are forced to use the hidden SSID
that is not the value that is actually be used for roaming determinations.
Is there an option or switch to force an update of the table for the value
which contains the hidden SSID of the currently associated channel?Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Hostap mailing list