Patch: running external commands from wpa_supplicant

[Jouni Malinen]

On Tue, Jan 11, 2005 at 08:08:59PM +0100, Henrik Brix Andersen wrote:

> I've written a preliminary patch for wpa_supplicant to allow running
> external commands (ifconfig, dhcp client, distribution specific
> scripts, ...) upon receiving various events.

This can potentially cause issues for number of time critical cases in
the supplicant code if the commands can block wpa_supplicant for too
long time. I don't see much point in running ifconfig from
wpa_supplicant; if the interface needs to be set UP, it could be done
from the driver handler init() function.

DHCP client and similar functionality would probably benefit more from
event notification or status query functionality that would allow them
to ask whether a given interface can be used for transmitting and
receiving data. This would happen completely outside wpa_supplicant with
drivers and/or kernel network stack. As an example, DHCP client could be
running all the time and it would decide when to acquiry a new lease
based on the network interface events.

As an alternative to the driver/network stack -based implementation,
these events could also be made available (and some of the are already)
through the wpa_supplicant control interface and its event delivery
mechanism. In this case, DHCP client would receive knowledge of the
interface vents through the control interface and it could also use this
interface to query the current status of the network interface.

I have not gone through the process of thinking about all common use
cases, so I may have missed something here. Please let me know if there
are operations that you believe would benefit from the use of external
commands from wpa_supplicant.

> The patch is not yet fully complete. I need advice on where to add the
> hooks for auth_cmd and reauth_cmd - see the patch for more details. The
> hook for startup_cmd is already in place.

These hooks were not described explicitly, but I would guess that by
auth_cmd you mean the moment when the data connection becomes usable
for the first time after starting wpa_supplicant and by reauth_cmd the
moment when data connection becomes (again) usable after roaming to
another AP.

At the moment, there is no clear location for this. This depends on the
selected security policy and the most likely places are the locations
calling wpa_supplicant_cancel_auth_timeout().

> The patch could be modified to use the exec family of system calls for
> executing the commands instead of using system(). This would allow
> running commands which are in PATH without specifying the full path to
> the binary, but I don't know how exec() influences portability?

Since this is limited to only one function, it would be easy to include
different implementation for cases where this is not available. One
could even consider forking a background job (when fork() or something
similar is supported) in order to avoid blocking wpa_supplicant.

> Perhaps it would be useful to have a shutdown_cmd as well? For bringing
> down the interface upon shutdown of wpa_supplicant?

That should probably be in driver deinit() handler (see driver_madwifi.c
for an example).

-- 
Jouni Malinen                                            PGP id EFC895FA