Hostpad modification

[Michael Alexeev]

Hello, hostapd developers.  Thank you for your work on hostapd. It has
been very useful to us in our test labs for the ISCS network security
management project (http://iscs.sourceforge.net).

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).

I do know that when I queried the netfilter mailing list to ask if
anyone had done this before with hostapd, there was some interest in
this functionality.  We have implemented it in a way specific to our
needs but would be willing to generalize it.  We see two paths to making
it more general.

So we have two questions:

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

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.
Of cause, all calls to the EP should be configurable.

Thanks,
Mike