Using wpa_supplicant/hostapd in IKEv2 daemon...

[Stjepan Gros]

Hi!

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).

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.

So, we have few more questions.

1. Can we use wpa_supplicant/hostapd as dynamic library, or only as
static one?

2. Do you have a link to some program that already uses
wpa_suppliant/hostapd as library?

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?

Note that we wish to make pulling latest code from
wpa_supplicant/hostapd as easy as possible.

Thanks for the answers,
Stjepan

On Sun, 2006-08-20 at 08:58 -0700, Jouni Malinen wrote:
> On Fri, Aug 18, 2006 at 08:54:36PM +0200, Stjepan Gros wrote:
> 
> > First idea is to implement everything from stretch and the second is to
> > take existing code base (like wpa_supplicant/hostapd) and integrate it
> > into IKEv2 daemon. But, those two ideas require too much resources that
> > we don't have now so we would like to avoid them.
> > 
> > Now, the third solution is to write glue layer that would allow us to
> > take and pass EAP messages from/to wpa_supplicant/hostapd.
> 
> I don't see how this would be less work than the second idea mentioned
> above.
> 
> > To minimize necessary changes we are thinking about leaving
> > wpa_supplicant/hostapd as a separate processes that communicate with
> > IKEv2 via some IPC mechanism. 
> 
> Well, I guess this would be possible, if IKEv2 interacts with EAP state
> machine in similar way as IEEE 802.1X/EAPOL. However, this brings in the
> complexity of possibly having to work around things that EAPOL state
> machines do. For example, re-tries are defined in EAPOL and I don't know
> whether the design there is compatible with IKEv2.
> 
> > 1. Generally, do you think is this idea feasible?
> 
> Feasible, yes, but certainly not the cleanest way of doing this.
> 
> > 2. We are thinking at implementing glue code at the l2_packet level,
> > that just relays EAP packet to IKEv2 daemon (and vice versa). That is in
> > wpa_supplicant. Is this the best place? Note that we need raw EAP
> > packets.
> 
> If you really want to go ahead with this in the way you described, yes,
> l2_packet would likely be the best place. However, I would strongly
> consider doing it at the architecturally correct place, i.e., next to
> EAP state machine, by implementing the EAPOL-EAP state machine interface
> (see eap.h). The names are referring to EAPOL, but there is no strict
> requirement of the other side really being EAPOL state machine, it could
> as well be IKEv2..
> 
> > 3. There are no such files (l2_packet*) in hostapd so where is the best
> > place to do such thing in hostapd?
> 
> l2_packet* are used with some driver interface. For example, see what
> driver_madwifi.c is doing with l2_packet for receiving and sending EAPOL
> frames.
> 
> 
> Anyway, I would be more interested in making sure that the EAP state
> machine can be used in other environments than trying to solve issues
> with EAPOL/IEEE 802.1X getting in way. The EAP code in wpa_supplicant
> has already been used in other systems than EAPOL/IEEE 802.1X, e.g.,
> with WiMax. You could try to use it as an external library in the IKEv2
> implementation.
> 
> I'm working on making the EAP server/peer implementations in
> hostapd/wpa_supplicant look more clearly as libraries for the next
> development branch (0.6.x). They already are mostly separate modules
> from rest of hostapd/wpa_supplicant and I would be willing to help with
> any remaining issue on this separation area if such issues show up with
> IKEv2.
>