Using wpa_supplicant/hostapd in IKEv2 daemon...
Mon Aug 21 09:12:14 PDT 2006
On Mon, Aug 21, 2006 at 04:27:36PM +0200, Stjepan Gros wrote:
> According to your answer we decided to use hostapd/wpa_supplicant as
> external library. Here is the basic idea we have so far:
> We would implement driver_ikev2.c that will communicate with IKEv2
> daemon and exchange EAP packets and control messages (we are not yet
> certain about control messages).
Hmm.. Is this driver_ikev2.c referring to something similar to other
driver_*.c files in hostapd/wpa_supplicant? If yes, then I would
recommend not doing this since the driver interface is not needed for
interacting with EAP state machine.
> State machine specific to IKEv2 will be implemented in ikev2_sm.c
> (analogously to eapol_sm.c). This file will implement interfaces defined
> in eap.h.
This would be the mechanism I would recommend. In other words, you would
drop all IEEE 802.11 code, WPA state machines, EAPOL state machines,
driver interface, ctrl_iface, etc. and just use the EAP state machine
and EAP methods. In addition, you would need to link in couple of
generic files providing helper functions and wrapper to TLS library. See
below for a quick example.
> 1. Can we use wpa_supplicant/hostapd as dynamic library, or only as
> static one?
Both would be fine. Though, use of wpa_supplicant/hostapd here could be
somewhat confusing, since this is not using all programs, just the EAP
peer state machine and EAP peer methods (from wpa_supplicant) and EAP
server state machine and EAP server methods (from hostapd).
> 2. Do you have a link to some program that already uses
> wpa_suppliant/hostapd as library?
Unfortunately, I don't think any of the projects (that I've heard of) is
> 3. In basic design of hostapd there is only one thread and that one is
> implemented in eloop.c. But, we need additional threads, and also, IKEv2
> daemon behaves differently than usual WLAN card. If we decide to run
> hostapd in separate thread, how to do it? Will there be any problems?
If you are taking just the EAP state machine, you do not need eloop.c
and you can then take care of using whatever thread model fits your
You will need to keep in mind that hostapd and wpa_supplicant were not
designed to be multi-threaded. I would expect most, if not all,
functions needed for the EAP code to be reentrant, but doing a quick
review on this area good be beneficial.
> Note that we wish to make pulling latest code from
> wpa_supplicant/hostapd as easy as possible.
I'm interested in cleaning up the interfaces in wpa_supplicant/hostapd,
if needed, so we should be able to make sure that the files are usable
as-is in this kind of use.
Since an example is likely to be more descriptive than my explanation
above, here's a minimal build sample for linking in EAP state machine
from hostapd into a standalone program:
int main(int argc, char *argv)
struct eap_sm *eap;
void *ctx = NULL;
struct eapol_callbacks cb;
struct eap_config conf;
/* TOOD: fill in callback functions and config */
memset(&cb, 0, sizeof(cb));
memset(&conf, 0, sizeof(conf));
eap = eap_sm_init(ctx, &cb, &conf);
if (eap == NULL)
/* TODO: use EAP (something similar to eapol_sm.c) */
build commands (simplified for clarity; these would likely be cleaned up
to use a Makefile; note that ../wpa_supplicant here refers to the CVS
version which has files in somewhat odd places; if you are looking at
the release tarballs, all files are in the same directory):
gcc -o libeap.a -c \
-I. -I../wpa_supplicant \
-DEAP_SERVER -DEAP_MD5 -DEAP_TLS -DEAP_PEAP -DEAP_TTLS \
-DEAP_MSCHAPv2 -DEAP_GTC -DEAP_TLV \
eap.c eap_methods.c eap_identity.c \
eap_md5.c eap_gtc.c eap_mschapv2.c eap_tlv.c \
eap_tls.c eap_peap.c eap_ttls.c eap_tls_common.c \
rc4.c sha1.c md5.c \
gcc -o sample_eap sample_eap.c \
-L. -leap \
-lcrypto -lssl \
-DEAP_SERVER -I. -I../wpa_supplicant
Jouni Malinen PGP id EFC895FA
More information about the Hostap