second(?) cut at (user space) 802.1x supplicant program.

first of all, I'm becoming slightly more proud of the code --
this is work in progress, the third(?) rough version that works.
it still needs cleaning up.

However, we have now better integration of the state
machine in a thread(2) programming style program.
we (try to) replace(d) synchronisation via global channels
by the use of channels.
In particular, the whole thing now runs at proper speed,
finishing in about two seconds, instead of the approx 20
seconds we needed earlier, because then, as it turned out,
we would process one packet and send the return in
two seconds.

Encountered and worked around a deadlock in
the Waiting state of ttls, where we might deadlock
if tlsClient needs more input than we can provide
before it will give output. i.e. tlsClient is hanging
in readN while we are waiting for it to either finish
or to give us message we can tunnel to the other side.
Added a timeout to catch this. The timeout makes us
go to Receive which means we return from ttls and
await more stuff - which may be a restart when the
other side times out??? If it is not a timeout, but
someone else it will confuse tlsClient enough to
exit with an error????

clean up in particular:
 - creating/parsing of messages [partly done]
 - debugging output (reduce amount, make more useful)
    [now -d is deprecated, lots of debug goes to syslog,
     should be changed. file server file?]
 - more robust message parsing (check all lengths)
    [tried to do this]
 - make sure we do the right thing when we 'hang'
    in the tls handshake, and have to clean up because
    in the middle of the tls handshake we receive a new
    Identity request - tlsClient may hang in readN)
    [high priority. now we threadkill the clientproc,
     and this may waste resources:
       keeping open handle to '#a/tls'
       consume memory somehow kept do to this]
 - fix the timers such that reset gets rid of one that
    hangs in sleep [high priority]
 - fix memory leak (certificate? sessionID?) [done, I think]

I hope this will happen in due time.

I'm making this available to allow constructive criticism.


This depends on:
 - the tlshand patches I submitted on sources/patch
    and which have been applied in the mean time
 - fastkey support in wlan driver
     (separate wavelan.[ch] etherwavelan.c)

It assumes a writable, append-only /sys/log/8021x file.
to which it writes _a_lot_ of debugging.

command line option -d outputs lots of debugging
command line option -D outputs tls handshake debugging

there are command line options to pass thumbprint directory,
and use the thumbprints to check certificate, but this
has never been tried.

we do not need to worry about TLS session resumption,
after the rewrite of the state machines + threadmain
the whole auth+keysetting now takes approx. 2 seconds
to complete (instead of the earlier 15 sec only needed
by tlsClient


TODO:
 - code cleanup
 - see  why we sometimes get error
        'invalid initial SSL2-like message' - this happens after
     an earlier fail, most likely we or the other side or both is/are
     confused after a first fail (incomplete cleanup? missing the
    right point (message) to continue?
 - test server certificate thumbprint checking 
 - reduce (debug) output to syslog
 - make the whole thing a file server?
    with e.g.
     - a ctl file for control messages (what kind of?)
     - a stats file for statistics (e.g. numbers suggested in 802.1x standard)
     - a log file, to which logging will be written if/when opened
     - a tlslog file, to which the tls handshake trace will be written,
        if/when opened
     - others?

Axel.Belinfante@cs.utwente.nl