Hostpad modification

[Michael Alexeev]

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

Ok, I see your point. But then my question would be  how can an external
program communicate its status  back to hostapd? For example, if it fails
then hostapd should not authenticate a port. If we do it again via
event back to the hostapd then by  the time hostapd receives the event
the port would be already opened.


> > 1) Would you consider this as a contribution to hostapd?
>
> Assuming it is contributed under a compatible license, yes.

Can we simply donate the code ?
>
>
> 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.

Does it mean that I can simply call hostapd_ctrl_iface_send to send a
byte stream to the external program from ieee802_1x_receive_auth, for
example?

>
> 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).
>
> --
I think that sending RADIUS message as-is and let external program
handle it is better option. This way hostapd won't spend extra time
parsing the message.

Thanks,
Mike