Double disconnect event

[Dan Williams]

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