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