<div dir="ltr">Thank you for your reply!<br><div><br>On Thu, Dec 27, 2012 at 4:43 PM, Jouni Malinen <span dir="ltr">&lt;<a href="mailto:j@w1.fi" target="_blank">j@w1.fi</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Dec 27, 2012 at 04:18:26PM -0500, Matt Causey wrote:<br>
&gt; I have a question that hopefully you can help me with.  We run<br>
&gt; wpa_supplicant 1.x and Linux 2.6.39 in a somewhat dense Cisco-based WLAN.<br>
&gt; There are lots of clients and they spend a lot of time roaming between<br>
&gt; access points.  Intermittently, the client gets into a state where<br>
&gt; wpa_supplicant has received an RSSI_LOW event, and has selected a BSSID<br>
&gt; that has better coverage.  The client gets to<br>
</div>&gt; ieee80211_send_probe_req&lt;<a href="http://lxr.free-electrons.com/ident?i=ieee80211_send_probe_req" target="_blank">http://lxr.free-electrons.com/ident?i=ieee80211_send_probe_req</a>&gt;()<br>
<div class="im">&gt; [1], and the BSSID that it has selected fails to respond to broadcast<br>
&gt; probes.:<br>
<br>
</div>Could you please test this with the current 2.0-devel snapshot of<br>
wpa_supplicant (i.e., snapshot of the master branch in<br>
git://<a href="http://w1.fi/srv/git/hostap.git" target="_blank">w1.fi/srv/git/hostap.git</a>)? There has been number of changes<br>
improving reaction to cases where authentication/association fails for<br>
whatever reason (very much including the cases where the AP network<br>
tries to use some proprietary load balancing mechanism that is likely<br>
the case here).<br></blockquote><div><br></div><div>I will give that a shot and let you know what we find.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im"><br>
&gt; In the 802.11 capture data, we see clearly that the client is sending valid<br>
&gt; Probe Requests, and the access point is failing to respond, though the same<br>
&gt; access point is responding to other clients.  We have the vendor engaged to<br>
&gt; answer the question of why the access point is not responding.<br>
<br>
</div>I&#39;d assume you have either load balancing or band steering enabled on<br>
the Cisco APs and that makes it not reply to some Probe Request frames.<br>
In this particular case the new AP seemed to be on the 5 GHz band, so<br>
I&#39;d assume this was not caused by band steering, but load balancing is<br>
likely to have similar effects. I cannot say that I like the way these<br>
APs try to force load balancing, but well, that&#39;s what&#39;s out there.. It<br>
is especially harmful with the mac80211 mechanism of using Probe Request<br>
frames to probe the specific AP and it would have been nice if that<br>
mechanism would have been used only for the broadcast probe case, but I<br>
guess it could apply here, too.<br>
<div class="im"><br></div></blockquote><div><br></div><div>We do have both &quot;Band Steering&quot; and &quot;AP Load Balancing&quot; disabled.  But I agree, it does indeed look as though the AP is being silent in an attempt to coerce the client into going to another AP. <br>
 <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br>
&gt; What appears to happen after the MLME layer issues the times-out, is that<br>
&gt; the supplicant then kicks off a scan and disconnects.  In our dense<br>
&gt; environment, this scan takes seconds to complete, and breaks our clients.<br>
&gt; In the case where these failures happen, the client already has a very full<br>
&gt; scan list that contains a lot of very solid roam choices.  Is there some<br>
&gt; way that I can cause the supplicant to attempt the next BSS on the list<br>
&gt; rather than invoking a whole new scan?<br>
<br>
</div>This is the part that has changed a lot in the latest wpa_supplicant and<br>
as such, I&#39;d like to see a debug log from such a run. wpa_supplicant<br>
should use the temporary blacklist mechanism to allow other BSSes to be<br>
tried and there is now some cases where the &quot;extra&quot; scan can be avoided<br>
or at least limited to a subset of channels (though, in your particular<br>
case, even that may end up being rather large set of channels). There is<br>
now better framework in place for allowing old scan results to be used,<br>
so it should be much easier to extend these mechanisms based on the new<br>
debug log if needed.<br></blockquote><div><br></div><div>Sounds great; thanks! Has the blacklist functionality improved in 2.x as well?  In the 1.x code it seems like on small lab networks we routinely get into a situation where we only have 2 APs online, one AP sends a Deauth for some valid reason, becoming blacklisted.  Then the client has nowhere to roam besides the AP he is on, so it repeatedly roams to itself at -80 RSSI until I manually clear the blacklist or bounce the supplicant. <br>
</div><div> <br>--<br></div><div>Matt<br><br></div></div></div></div></div>