wpa_supplicant dbus interface & reassociate() method

[Fionn Cleary]

Hi,

I?m currently playing with a little app which interfaces with
wpa_supplicant via dbus, and I have discovered that I need to use send
the reassociate command to wpa_supplicant to get wpa_supplicant to try
any of the configured networks. (I am aware of SelectNetwork, and that
isn?t what I want do do) I discovered that the dbus interface does
actually have a reassociate method, which was great until I discovered
that it only seems to work if wpa_supplicant is already connected, which
is not the case in my app.  Checking through the code in
ctrl_iface.c:6061 (the standard ctrl_iface control connection) shows

1) REASSOCIATE works when the interface is not disabled.
2) REATTACH works when the interface is not disabled && there is a
   current ssid.
3) RECONNECT works when the interface is not disabled && it is in the 
   disconnected state.

However, the code in dbus_new_handlers.c:1476 for the
wpas_dbus_handler_reassociate function checks for a current ssid; ie, it
only works when REATTACH would have worked, and the next function (line
1498) is wpas_dbus_handler_reattach which does exactly the same thing as
wpas_dbus_handler_reassociate, but also sets the ?reattact? flag for
wpas_request_connection().

?Works? in the above text means ?call wpas_request_connection()? (and
connects to any configured network).

Could anyone clarify why the reassociate() dbus method has different
behaviour to the REASSOCIATE command for ctrl_iface?  I?m guessing that
the current behaviour of the dbus reassociate method is a bug, but I?d
like to get some confirmation.

The reassociate method is also missing from the dbus documentation in
the doc/ directory, I could prepare a patch for it if I could determine
what exactly the method is meant to do.

The reassociate method was added by this patch:

http://lists.shmoo.com/pipermail/hostap/2012-August/026464.html

Thanks,
Fionn