Hostpad modification

[Jouni Malinen]

On Wed, Aug 01, 2007 at 09:41:35PM -0400, Michael Alexeev wrote:

> As part of our work, we needed to make some modifications to hostapd and
> would like to return them to the community if you are interested in
> accepting them.  We needed a way to call an external script after
> successful authentication and just before opening the port in order to
> dynamically change the firewall rules.  We needed to pass to this script
> the MAC address, port name and RADIUS attributes.  We also needed to
> remember that information so we could undo those rules upon client
> disconnection (and hence another call to an external script).

Please note that due to the single-threaded design, none of the
operations in hostapd should block and in general, I do not like the
idea of calling an external script from the hostapd process. In other
words, this type of operations should be done in the same way as was
done for action scripts in wpa_supplicant, i.e., by using an external
program to listen for events from hostapd (and if desired, the external
program can then run a script based on these events). This allows
hostapd to continue processing other requests which may be time
sensitive (like processing probe requests).

> 1) Would you consider this as a contribution to hostapd?

Assuming it is contributed under a compatible license, yes.

> 2) If so, which of the two styles of implementation described below
> would you prefer.
> 
> In either case  the entire ACCESS-ACCEPT RADIUS message needs to be
> passed to the external process (EP) for further processing in order to
> hide application specific processing from hostapd. It could be done
> via
> serializing the entire message to make it look like a collection of
> name-value pairs and passing it as a string argument to the EP or via binary
> stream using interprocess communication (pipe, for example) between the
> hostapd and the EP. Both approaches have their pros and cons. Passing RADIUS
> message as a string implies that EP could be a simple script to parse the
> string but in that case hostapd must do the main work of serializing the
> attributes. The downsize of it is that if only a single attribute is needed
> the entire message still needs to be serialized. By opening a pipe and
> sending the entire meesage as a binary stream to the EP the second approach
> avoids such inefficiency by shifting all complexity to the EP itself
> but at a price
> of making it a full blown program.
> In either case the EP then could persist data (if needed) for the later use
> during the disconnect call.

Taken into account my comment above about running scripts from hostapd,
I think there will be need to run an external program that is bit more
than just a shell script anyway.. At this point, hostapd has support for
external programs that use a control interface (over UNIX domain
socket). This interface can be used to attach external programs to
monitor event notification from hostapd. However, at this point no such
events are actually generated, but hostapd_ctrl_iface_send() function is
available for doing this.

The control interface is using text-based commands and it would be nice
to continue this for the events, too. In other words, the RADIUS message
payload would either need to be sent as a hexstring to all monitor
programs or taken into account its size, this could actually be handled
differently by allowing the external programs to request these events to
be sent with full data (and at that point, even binary version could be
fine since other monitor programs would not be receiving these).

As far as sending the full RADIUS message as-is vs. parsing and sending
each attribute as a "name=value" item is concerned, I don't have much
preference either way. Anyway, it may end up being simpler to just send
the full message as-is since that would allow encoding of various
attribute formats to be ignored (e.g., sending binary data as a text
name=value string is bit complex unless hex string is used for all
attributes and at that point, a simple script might not be able to use
this that easily anyway).

-- 
Jouni Malinen                                            PGP id EFC895FA