On Sun, Dec 4, 2011 at 12:17 PM, Jouni Malinen <span dir="ltr">&lt;<a href="mailto:j@w1.fi">j@w1.fi</a>&gt;</span> wrote:<br><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 Tue, Sep 27, 2011 at 04:35:02PM +0200, Johannes Berg wrote:<br>
&gt; On Wed, 2011-09-21 at 11:36 -0700, Sam Leffler wrote:<br>
</div><div class="im">&gt; &gt; I totally agree.  Since that patch I had to fix some edge cases and<br>
&gt; &gt; there may still be more.  I think to make this work right it needs to<br>
&gt; &gt; be carefully tied to the SME pieces of supplicant or madness will<br>
&gt; &gt; ensue.  OTOH all this could be dramatically simplified if one could<br>
&gt; &gt; just re-auth w/o having to re-establish the BSS entry in the kernel by<br>
&gt; &gt; doing the 1-channel scan...<br>
<br>
</div><div class="im">&gt; I don&#39;t think it&#39;s actually possible though since we rely on the BSS<br>
&gt; entry for a whole bunch of things like knowing what we&#39;re connected to.<br>
<br>
</div>This is probably fine as long as you can use wpa_supplicant for the<br>
connection.. If you try to implement your own nl80211 commands and SME<br>
handler, you&#39;ll likely soon wish you had used something that had already<br>
implemented this.. ;-)<br>
<div class="im"><br>
&gt; Maybe it&#39;d be possible to hide it in driver_nl80211?<br>
<br>
</div>Yes, that sounds like a good approach here and it certainly makes core<br>
wpa_supplicant implementation much simpler. This turned out to be quite<br>
a bit of code, but it&#39;s there now:<br>
<br>
commit 536fd62dba5480a2490726f0e3a9bc38225b0904<br>
    nl80211: Recover from auth req ENOENT with a scan<br>
 1 file changed, 149 insertions(+)<br>
<br>
<br>
The core code changes to kick this on recoverable reason codes in<br>
deauth/disassoc:<br>
<br>
commit d00821e913eda00e3c61aaacc78687766f150d11<br>
    Try to reconnect to the same BSS on recoverable disconnection<br>
 1 file changed, 34 insertions(+), 3 deletions(-)<br>
<br>
<br>
This goes through all the wpa_state values in the same way as normal<br>
connection would (well, apart from SCANNING). In the case the cfg80211<br>
BSS entry exists, the reconnection is pretty much instant. In case the<br>
single channel scan has to be done, about 100 msec seems to get added<br>
(with mac80211_hwsim; maybe some more with real hardware).<br>
<br>
I&#39;ve done only limited testing on this so far and would be interested in<br>
hearing whether this addresses all optimizations done in the chromiumos<br>
patches (there was more than just the one posted on this list). At least<br>
the filtering of old scan results is not included here, so it might be<br>
worth consideration of adding it.<br>
<br>
Actually, the scan results are not even fetched to user space at this<br>
point, so BSS missing from there would not be noticed anyway.. Though,<br>
it should be easy to fetch the results for this special<br>
within-driver_nl80211.c scan, too, and at least check that the target<br>
BSS is included. Now this happens kind of implicitly if the second<br>
attempt at nl80211 auth command fails.<br><font color="#888888"><br></font></blockquote><div><br></div><div>These changes fail our roaming test suite (which explicitly check fast reconnect).  A quick glance indicates at least some failures are due to the cached scan results.  I&#39;ll have to go through the logs to understand.</div>
<div><br></div><div>As to other changes in our code base that are not in yours; I pulled our supplicant code forward to your ToT and it looks like we&#39;ve got 3 differences:</div><div><br></div><div>1. support for raw psk</div>
<div>2. bgscan_simple algorithm changes</div><div>3. better roaming (but still not complete)</div><div><br></div><div>You can find our stuff by searching for commits marked CHROMIUMOS <a href="http://git.chromium.org/gitweb/?p=chromiumos/third_party/hostap.git;a=summary">here</a>.</div>
<div><br></div><div>-Sam</div></div>