wpa_supplicant and hostapd support for WiMAX authentication

[Jouni Malinen]

On Mon, Mar 26, 2007 at 02:23:04AM +0800, Macpaul Lin wrote:

> Actually, I've already traced the eapol_sm.c before receving the detail
> information from you ;).
> I just wondering if there is any way to change the behavior of state machine
> from driver interface?

No.

> If hostapd/wpa_supplicant can support different intermedate protocol (EAPOL)
> driver will be more flexible to integrate into different system. Take WiMAX
> as a example, it seems there will be more and more different new
> technologies to integrate EAP into the system without EAPOL.

You can replace eapol_sm.c with another implementation that uses
different protocol.

I'm trying to understand what parts of wpa_supplicant would be of use
for WiMAX. Are you really using the driver interface with a WiMAX
driver? How many of the driver_ops functions apply to that use? I can
certainly understand the part of using EAP peer state machine and
methods, but I don't see much benefit of EAPOL state machine (apart from
being an example on how to interact with EAP) or WPA/802.11i state
machines. Is any of the event handling and AP selection code of use?

> Yes, Yes. Since there are so many different WiMAX (802.16e) solutions,
> Intel, Sequence, Runcom, Beceem.
> It's hard to make wpa_supplicant be suitable for each implementatoin.
> I can do some hardcoded modify to made wpa_supplicant to adapt to the
> solution that I'm working on.

Would you be able to describe what kind of interface you get from the
rest of the system? Is all 802.16e message handling implemented in the
driver? How would EAP peer implementation interact with whatever
component actually sends the frames out?

> That's why I'm looking for the core developement team's help to made the
> supplicant can be adaptable to other technologies.
> For example, for the solution I'm working on, replace EAPOL with vendor
> depented protocol (control command) is enought.
> If EAPOL can be repleaced with other intermediate protocol as easy as
> runtime parameters or compile-time options,
> then the integration to other technology can be more easier and the code can
> be more reusable.

Just replacing EAPOL sounds bit odd, since I don't see much use for the
layers that are on top (or on side in some cases) of it. I do try to
make it clearer that EAP state machine and methods can be used without
rest of wpa_supplicant, but I would really need to get more detailed
description of needs for anything else before I could design suitable
interfaces to allow it to be used. Just "replace EAPOL" is not
reasonable for most (all?) cases..

> Hmm, I'm very happy to do it so but since I'm working for my company ;p
> It depends on how the source of linux driver and control interface can be
> released.
> It seems both the driver and the interface remains proprietary currently.
> However, the linux driver and control interface of the solution I'm working
> on can be reverse engineered easily I think ;-)

I'm not interested in wasting time on reverse engineering. I would be
happy to help here, but I would need to get some level of details on the
interfaces with which code from wpa_supplicant would interact.

> So, if you can made EAPOL can be overrode with other protocol or can be
> overrode with driver interface just like function overriding of
> send_eapol(). It will be helpful to integrade with other technology.

EAPOL state machine implements quite a bit more than just encapsulation
of frames. The state machine is used to control many aspects of the
authentication process.

Like I said, I'm all for making this easier to use with other
technologies, but being able to do this requires certain level of
technical details to be available.
 
-- 
Jouni Malinen                                            PGP id EFC895FA