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