Double disconnect event

Dmitry Shmidt dimitrysh at google.com
Wed Mar 10 18:32:53 EST 2010


On Wed, Mar 10, 2010 at 1:25 PM, Jouni Malinen <j at w1.fi> wrote:

> On Mon, Mar 08, 2010 at 12:27:22PM -0800, Dmitry Shmidt wrote:
>
> > 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.
>
> Are you saying that the network manager would send new commands between
> the two DISCONNECT events to request a connection with another network?
> And the problem is with there not being enough information to be able to
> figure out which connection is being "disconnected"?
>

Yes


>
> > 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 is different event than the one your proposed patch for trying to
> suppress.. I do not think I would support the proposed change (suppress
> the event in driver_wext.c), but I could consider a change to make sure
> the DISCONNECT ctrl_interface event (or D-Bus for that matter if
> applicable) is of more use to external programs.
>

The problem is that WEXT distinguishes between EVENT_ASSOC and
EVENT_DISASSOC if BSSID is set or 0.
So there is no easy way to understand if this is DISASSOC from "old" BSSID
or new one


>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> 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/20100310/fbe100a9/attachment-0001.htm 


More information about the HostAP mailing list