initial CONNECTED events sometimes missed

[Jouni Malinen]

On Sun, Nov 18, 2007 at 03:58:56AM +1000, Kel Modderman wrote:

> Yeah, I can enable/disable network that had already succeeded, or toggle the 
> rkfill switch or depend on wpa_cli/wpa_gui + brain to configure each time...
> 
> All this human input is what I'd like to remove from the process of connecting 
> to known networks ;-). wpa_supplicant has the power, it just seems I've 
> struck race between slow to attach wpa_cli, and fast to associate network.

I was assuming that you would have a script for doing this and
consequently, the disabling and enabling of the networks would be just a
change to that script.. If someone needs to manually run wpa_supplicant
and wpa_cli/wpa_gui in the first place, this is not exactly well
integrated to the distro.. ;-)

> Ideally the supplicant should wait until the ATTACH signal from the monitor's
> wpa_supplicant_ctrl_iface_attach attempt has been processed by
> wpa_supplicant_ctrl_iface_wait. This would ensure that it is ready to receive
> event signals (and not still in process of attaching), and conform to the
> advertised semantic of "wait for a control interface monitor before starting".
> 
> I guess this can be done by performing what wpa_supplicant_ctrl_iface_receive
> normally would in the event of receiving an ATTACH signal from the ctrl_iface.
> 
> The below hack allows monitor interface to reliably capture the initial
> CONNECTED event signal more reliably, as seen by debug output below hack.

Thanks! While this has some duplicated code, I really like the part of
this still being contained in a single function.. I did some minor
cleanup for the patch and ended up adding it to the 0.6.x branch since I
don't see any better solution for the problem.

-- 
Jouni Malinen                                            PGP id EFC895FA