Double disconnect event
Wed Mar 10 15:32:53 PST 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
> > 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
> > 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"?
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Hostap