Double disconnect event
Wed Mar 10 13:25:40 PST 2010
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"?
> 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.
Jouni Malinen PGP id EFC895FA
More information about the Hostap