<div dir="ltr"><i> <br>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.<br><br>
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 &gt; 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?<br><br>Regards, <br>Dan</i><br></div>