Disconnect event from the wpa_supplicant looks like:<br>&quot;CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys&quot;<br><br><div class="gmail_quote">On Tue, Mar 9, 2010 at 4:09 PM, Dan Williams <span dir="ltr">&lt;<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Mon, 2010-03-08 at 12:27 -0800, Dmitry Shmidt wrote:<br>
&gt; Hi Jouni,<br>
&gt;<br>
&gt; How double-disconnect event may cause the problem?<br>
&gt; Let&#39;s assume we are switching from one network (AP) to another.<br>
&gt; What I see that we got first DISCONNECT event, then ASSOCIATING, and<br>
&gt; then we may get another DISCONNECT event.<br>
&gt; It happens probably because single-threaded wpa_supplicant can process<br>
&gt; messages when it can.<br>
&gt; Network manager get first DISCONNECT event and schedules to do<br>
&gt; something. Then it gets another one (the same actually from network<br>
&gt; perspective) and schedules another &quot;disconnect&quot; procedure that may<br>
&gt; take place after we were already associated with another network.<br>
<br>
</div>If the disconnect event is for the same network, shouldn&#39;t the<br>
connection manager be able to figure that out and handle it<br>
appropriately by not scheduling a second disconnect procedure? I&#39;m<br>
assuming that the connection manager keeps around a &quot;this is the AP I&#39;m<br>
connecting to&quot; variable somewhere, in which case it should be trivial to<br>
figure out what&#39;s going on.  Unless you&#39;re just pushing a bunch of<br>
networks to the supplicant config and letting the supplicant handle the<br>
network choice.<br>
<div class="im"><br>
&gt; So my point is that double-disconnect event doesn&#39;t help the system to<br>
&gt; be more robust. You may raise an objection that network manager should<br>
&gt; take care of it. But there is no way for network manager to know if it<br>
&gt; is &quot;old&quot; DISCONNECT or new one when we failed with new network.<br>
<br>
</div>This could be the case if you&#39;re pushing a bunch of configuration to the<br>
supplicant and letting it figure out the network to connect to I guess.<br>
But at that point, don&#39;t you have messages from the supplicant telling<br>
you *which* AP the supplicant is now trying to connect to, and thus your<br>
connection manager knows when the disconnect event comes in which<br>
network it&#39;s for?<br>
<font color="#888888"><br>
Dan<br>
</font><div><div></div><div class="h5"><br>
&gt; Thanks,<br>
&gt;<br>
&gt; Dmitry<br>
&gt;<br>
&gt; On Sat, Mar 6, 2010 at 1:01 AM, Jouni Malinen &lt;<a href="mailto:j@w1.fi">j@w1.fi</a>&gt; wrote:<br>
&gt;         On Mon, Feb 22, 2010 at 03:41:51PM -0800, Dmitry Shmidt wrote:<br>
&gt;<br>
&gt;         &gt; Working with several WEXT-supported driver I see that they<br>
&gt;         are sending<br>
&gt;         &gt; SIOCGIWAP event<br>
&gt;         &gt; (DISASSOCIATE) for both DISASSOCIATE and DEAUTHENTICATE<br>
&gt;         internal driver events<br>
&gt;         &gt; by using<br>
&gt;         &gt;   wireless_send_event(SIOCGIWAP);<br>
&gt;         &gt;<br>
&gt;         &gt; In case of AP with no security it will be just one message,<br>
&gt;         but<br>
&gt;         &gt; otherwise it will send the message twice.<br>
&gt;         &gt; driver_wext.c event handling will call<br>
&gt;         &gt;    wpa_supplicant_event(ctx, EVENT_DISASSOC, NULL);<br>
&gt;         &gt; twice for each of driver&#39;s events with small delay.<br>
&gt;<br>
&gt;<br>
&gt;         This sounds reasonable.<br>
&gt;<br>
&gt;         &gt; It is not a big deal for wpa_supplicant itself but it may<br>
&gt;         confuse<br>
&gt;         &gt; network manager.<br>
&gt;<br>
&gt;<br>
&gt;         Could you please provide more details on why and how this<br>
&gt;         would confuse<br>
&gt;         network manager?<br>
&gt;<br>
&gt;         &gt; Will it be &quot;safe&quot; to suppress the second message on<br>
&gt;         driver_wext.c layer?<br>
&gt;         &gt; Am I missing something?<br>
&gt;<br>
&gt;<br>
&gt;         Whether it is safe or not, I&#39;m missing details on why it would<br>
&gt;         be<br>
&gt;         desirable to suppress the second event.. ;-) Unless a clear<br>
&gt;         issue can be<br>
&gt;         identified, I would rather not make wpa_supplicant filter<br>
&gt;         events in this<br>
&gt;         way.<br>
&gt;<br>
&gt;         --<br>
&gt;         Jouni Malinen                                            PGP<br>
&gt;         id EFC895FA<br>
&gt;         _______________________________________________<br>
&gt;<br>
&gt;<br>
&gt;         HostAP mailing list<br>
&gt;         <a href="mailto:HostAP@lists.shmoo.com">HostAP@lists.shmoo.com</a><br>
&gt;         <a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; HostAP mailing list<br>
&gt; <a href="mailto:HostAP@lists.shmoo.com">HostAP@lists.shmoo.com</a><br>
&gt; <a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
<br>
<br>
</div></div></blockquote></div><br>