wps_enrollee cleaned up code

Ted Merrill ted at atheros.com
Mon Nov 12 16:47:56 EST 2007

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 

Several other issues i will address in the next week or two (see below).

Ted Merrill
Atheros Communications


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

More information about the HostAP mailing list