initial CONNECTED events sometimes missed

[Jouni Malinen]

On Thu, Nov 15, 2007 at 12:11:13AM +1000, Kel Modderman wrote:

> CTRL_IFACE - eth1 - wait for monitor
> CTRL-EVENT-CONNECTED - Connection to 00:09:5b:2a:92:2e completed (auth) [id=0 id_str=clangord]
> CTRL_IFACE monitor attached - hexdump(len=21): 2f 74 6d 70 2f 77 70 61 5f 63 74 72 6c 5f 37 31 36 31 2d 30 00

> Now we get to the point where the wpa_cli daemon is ready to monitor events,
> but the CTRL-EVENT-CONNECTED has already passed. The interactive wpa_cli
> instance remains empty until something else happens.
> 
> As I understand it, wpa_supplicant uses eloop_wait_for_read_sock() as a
> blocking function until anything attaches to the ctrl socket. wpa_cli sends
> "ATTACH" to the socket when it does attach which will allow wpa_supplicant to
> continue. But is wpa_cli really ready to monitor events at this time?

Well, wpa_cli itself would likely be ready, but it has not yet been
attached to actually receive any events from wpa_supplicant.. It is
somewhat surprising to see it take that long for wpa_cli to send the
ATTACH command in this case, though.

I think the safest option would be to start wpa_supplicant without an
active configuration (e.g., all networks disabled or no networks
configured), start wpa_cli for monitoring events, and then use another
wpa_cli command to enable configuration/network..

Waiting for the ctrl_iface monitor to attach to the interface could be
done differently, but I'm not sure how cleanly that can be done.. The
current version is, in practice, using a blocking call for this. This
would need to be modified to enable some functionality (ctrl_iface
message processing), but not anything else. I would be open to changing
this if this can be done cleanly, but I do not think I would like to see
major changes to resolve this case and would just end up recommending
the safer workaround I mentioned above.

-- 
Jouni Malinen                                            PGP id EFC895FA