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