wps_enrollee cleaned up code

[Ted Merrill]

Jouni has placed the code at:
http://w1.fi/contrib/hostap-wps-20071112.tgz
Please note that although this works (under Linux) it is not a complete WPS 
solution (it does not include scanning; you must provide the SSID) and 
architecturally it leaves something to be desired (the wps_enrollee program 
does things that would be better done inside of wpa_supplicant); and it does 
not put it's output in a convenient form.
I'll be making another release soon that should address most of these issues.

-Ted Merill
Atheros Communications


On Monday 12 November 2007 13:47:56 Ted Merrill wrote:
> Hi Jouni,
>
> By separate email i'll be sending you the cleaned up WPS enrollee code
> (since i know that it is too large to pass through the email filter)...
> could you please post it? ... and more importantly, review it and when
> possible add to the hostap tree.
>
> I've cleaned up the style considerably to agree with the style that you
> use. Please let me know what else needs to be done re. style or more
> substantive issues.
>
> Several other issues i will address in the next week or two (see below).
>
> Thanks,
> Ted Merrill
> Atheros Communications
>
> Details:
>
> Logically, the new wps_enrollee sits above and commands wpa_supplicant,
> which continues to run... see below.
> It also however makes direct l2_packet calls.
> It could be argued that wps_enrollee should make use of the EAP code used
> elsewhere, but i think this would only serve to confuse.
> Although WPS >uses< the EAP mechanism, WPS is not actually an
> authentication protocol at all... using EAP is basically just a hack.
>
> Static data is almost entirely eliminated; state data pointer is passed as
> first argument to every function.
>
> The code is modularized into the following components:
> -- wpse_defs.h -- shared definitions (some of which will be useful for wps
> server).
> -- wps_crypto -- key generation, authentication generation and checking.
> The state data consists only of key data.  Relies on the same underlying
> crypto routines as wpa_supplicant does (including can use the compact
> internal routines).  Some of this will be useful for wps server.
> -- wpse_parse -- parses input args, configuration files, etc. that
> determine how enrollee side wps is done.
> -- wpse_sm - enrollee state machine. The state data for the state machine
> consists of: configuration parameters; copies of packets sent and received;
> key state.  wpse_sm does NOT send or receive any packets, nor does it
> generate timeouts,  instead the next higher level queries wpse_sm and does
> the jobs for it.  This will simplify using this code in e.g. new embedded
> applications.
> -- wpse_supplicant -- enrollee interface to the supplicant, it commands the
> supplicant (via wpa_ctrl mechanism, using socket files on linux) to
> associate with the desired ssid in open mode... note that wpa_supplicant
> runs the whole time. This portion could be easily replaced to e.g. perform
> supplicant actions directly.
> -- wpse-job -- enrollee wps job. This uses wpse_sm and wpse_supplicant as
> well as the l2_packet interface of wpa_supplicant (for sending/receiving
> packets) and eloop (for timeouts and file descriptor polling).
> -- wpse-save -- functions to save the results in various formats.
>
> Currently, wps_enrollee is a separate program, and no modifications to
> wpa_supplicant were necessary (except for the Makefile and defconfig, to
> make wps_enrollee)... this is certainly the safe road for early
> development. I've gotten the feedback from you that for various reasons it
> would be better if it were part of wpa_supplicant.  My thinking is that it
> can be linked as part
> of the wpa_supplicant program yet still logically sit above (the rest of)
> wpa_supplicant... i hope you agree with that. My intention is to extend
> the wpa_ctrl mechanism to include control from within the same process or
> just bypass wpa_ctrl entirely.
>
> Currently there are some pieces missing from what i've done.
> You have to specify an interface name; it should be possible to
> automatically detect the interface, at least if there is only one.
> More importantly, you have to specify the ssid; i need to add the scanning
> code that will detect the available APs for the selected pushbutton
> (default) or pin mode... this will require some extension to the wpa_ctrl
> command set. Inclusion of wps ie into probe requests is a TODO also.
> Currently if using pin mode, you have to provide the pin; for convenience
> (?) i'll add something to automatically generate a pin, although i'm not
> sure how useful this would be in production software.
>
> The wpa_ctrl mechanism is in my opinion rather weak, and could use some
> extensive rework (in contrast to most of your code which is quite good).
> It uses a text based communication protocol which isn't very easy to
> extend. I'll have to think about whether to dive into this, probably i'll
> just have to live with it... or abandon using wpa_ctrl.