Double disconnect event

[Dan Williams]

On Tue, 2010-03-09 at 16:17 -0800, Dmitry Shmidt wrote:
> Disconnect event from the wpa_supplicant looks like:
> "CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys"

Right, but that should be  matched up with a previously emitted "trying
to associate with" message, right?  Like from wpa_supplicant_associate()
where it logs:

	wpa_msg(wpa_s, MSG_INFO, "Trying to associate with SSID '%s'",
		wpa_ssid_txt(ssid->ssid, ssid->ssid_len));

now obviously that's not a normal ctrl iface "event", but perhaps it
should be?  That would be my preferred solution, to create a 

#define WPA_EVENT_ASSOCIATING "CTRL-EVENT-ASSOCIATING "

event with the AP's SSID and then pushing that out to the client over
the control interface.  Thus, your client can figure out when you've
gotten more than one disconnect event for the same network and not
schedule the disconnect action again if it's still pending.

Dan

> 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
>         
>         
>         
>