wpa_supplicant dbus interface & reassociate() method

Fionn Cleary clearyf at tcd.ie
Thu Apr 3 12:17:07 EDT 2014


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

“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:



More information about the HostAP mailing list