EAP peer implementation from wpa_supplicant as a library

Alan DeKok aland
Sun Dec 9 10:31:36 PST 2007


Jouni Malinen wrote:
> That looks quite interesting combination ;-). Nice to hear it worked.

  "works".  It will take a little more code before it works for people
other than myself.

  But it's ~1k LoC, most of which is cut & pasted from other modules, or
from the eap_example code.  A small additional amount of code will make
it production-ready.

> While implementing the eap_example code, some areas started looking
> worse than I had hoped for and I think I will end up cleaning the
> interface a bit to make it less complex and to require less code in
> whatever is using the EAP state machine. Though, this is more on the EAP
> peer side, so that part may not touch the particular example you showed
> above. I already did some cleanup on the server side some time ago when
> updating hostapd EAPOL/EAP state machine interfaces.

  The interface right now looks pretty good.  Some comments:

 - exposing TTLS TLV data to the server would be useful
 - allowing the server to add TTLS TLV data would be useful
 - having method checks for PAP/CHAP/MS-CHAP in phase 2
   like is done for the EAP methods would be useful
 - ability to completely control phase2 method would be good
   i.e. run one EAP library for phase1, and another for phase2
   it's weird, but it can catch corner cases and assumptions

> In addition, I have a longstanding to-do item on implementing a generic
> buffer data structure for dynamic memory buffers. If I end up finishing
> this finally, that would change the EAP interfaces from passing in
> pointer to u8* and length to using a pointer to struct wpabuf which
> would have accessor functions for getting pointers/length for the
> included data.

  Sounds good.

  Alan DeKok.




More information about the Hostap mailing list