Double disconnect event

[Dmitry Shmidt]

Disconnect event from the wpa_supplicant looks like:
"CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys"

On Tue, Mar 9, 2010 at 4:09 PM, Dan Williams <dcbw at redhat.com> wrote:

> On Mon, 2010-03-08 at 12:27 -0800, Dmitry Shmidt wrote:
> > Hi Jouni,
> >
> > How double-disconnect event may cause the problem?
> > Let's assume we are switching from one network (AP) to another.
> > What I see that we got first DISCONNECT event, then ASSOCIATING, and
> > then we may get another DISCONNECT event.
> > It happens probably because single-threaded wpa_supplicant can process
> > messages when it can.
> > Network manager get first DISCONNECT event and schedules to do
> > something. Then it gets another one (the same actually from network
> > perspective) and schedules another "disconnect" procedure that may
> > take place after we were already associated with another network.
>
> If the disconnect event is for the same network, shouldn't the
> connection manager be able to figure that out and handle it
> appropriately by not scheduling a second disconnect procedure? I'm
> assuming that the connection manager keeps around a "this is the AP I'm
> connecting to" variable somewhere, in which case it should be trivial to
> figure out what's going on.  Unless you're just pushing a bunch of
> networks to the supplicant config and letting the supplicant handle the
> network choice.
>
> > So my point is that double-disconnect event doesn't help the system to
> > be more robust. You may raise an objection that network manager should
> > take care of it. But there is no way for network manager to know if it
> > is "old" DISCONNECT or new one when we failed with new network.
>
> This could be the case if you're pushing a bunch of configuration to the
> supplicant and letting it figure out the network to connect to I guess.
> But at that point, don't you have messages from the supplicant telling
> you *which* AP the supplicant is now trying to connect to, and thus your
> connection manager knows when the disconnect event comes in which
> network it's for?
>
> Dan
>
> > Thanks,
> >
> > Dmitry
> >
> > On Sat, Mar 6, 2010 at 1:01 AM, Jouni Malinen <j at w1.fi> wrote:
> >         On Mon, Feb 22, 2010 at 03:41:51PM -0800, Dmitry Shmidt wrote:
> >
> >         > Working with several WEXT-supported driver I see that they
> >         are sending
> >         > SIOCGIWAP event
> >         > (DISASSOCIATE) for both DISASSOCIATE and DEAUTHENTICATE
> >         internal driver events
> >         > by using
> >         >   wireless_send_event(SIOCGIWAP);
> >         >
> >         > In case of AP with no security it will be just one message,
> >         but
> >         > otherwise it will send the message twice.
> >         > driver_wext.c event handling will call
> >         >    wpa_supplicant_event(ctx, EVENT_DISASSOC, NULL);
> >         > twice for each of driver's events with small delay.
> >
> >
> >         This sounds reasonable.
> >
> >         > It is not a big deal for wpa_supplicant itself but it may
> >         confuse
> >         > network manager.
> >
> >
> >         Could you please provide more details on why and how this
> >         would confuse
> >         network manager?
> >
> >         > Will it be "safe" to suppress the second message on
> >         driver_wext.c layer?
> >         > Am I missing something?
> >
> >
> >         Whether it is safe or not, I'm missing details on why it would
> >         be
> >         desirable to suppress the second event.. ;-) Unless a clear
> >         issue can be
> >         identified, I would rather not make wpa_supplicant filter
> >         events in this
> >         way.
> >
> >         --
> >         Jouni Malinen                                            PGP
> >         id EFC895FA
> >         _______________________________________________
> >
> >
> >         HostAP mailing list
> >         HostAP at lists.shmoo.com
> >         http://lists.shmoo.com/mailman/listinfo/hostap
> >
> >
> > _______________________________________________
> > HostAP mailing list
> > HostAP at lists.shmoo.com
> > http://lists.shmoo.com/mailman/listinfo/hostap
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20100309/2e1cf89a/attachment.htm