user space 802.1x supplicant program.

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

This version finally seems to get the cleanup right --
as much as any method using threadint can be right
(see the discussion in thread "thread confusion" on 9fans).
The main reason it now works is most likely that now
I give tlsClient some time to hang itself up in read
before I fire a threadint at it.
In the past the chances were greater that threadint
might arrive while tlsClient was doing something else
(not hung in a system call but just some computation)
at which point the threadint was lethal since
no note handler was/is installed.
This is the last version that will employ threadint.
I will use the workaround discussed in "thread confusion"
on 9fans and hope that allows me to clear away _a_lot_
of the 'administration'.

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', in particular
          to #a/tls/X/hand' while handshake was going on,
          ties up a '#a/tls' instance
       - consume memory somehow kept do to this]
   [updated to instead threadint the clientproc,
    hoping this will take it out of readN, if necessary,
    and still gives it the opportunity to clean up]
 - fix the timers such that reset gets rid of one that
    hangs in sleep [high priority]
    [restructured the timer stuff, better but still not perfect]
 - 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?
   [seems we now know this]
 - test server certificate thumbprint checking
    [not tested, but we have code that is supposed to work[
 - 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