Double disconnect event

[Jouni Malinen]

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