wpa_supplicant and hostapd support for WiMAX authentication

[Macpaul Lin]

> Jouni Malinen wrote:

[deleted..]

> Yes, WiMAX uses its own mechanism for tunneling EAP authentication
> instead of using IEEE 802.1X like IEEE 802.11 is.

[deleted..]

> > Is there any way to disable or strip EAPOL header off to make
> > wpa_supplicant/hostapd support some WiMAX sulotion's authentication
process?
> > Is any state machine or RX handling function need to be modified since
it
> > seems EAPOL is hard implemented into the core of wpa_supplicant/hostapd.

> In general, there are two options for using code from
> wpa_supplicant/hostapd with WiMAX. One option is to just use the EAP
> server/peer implementation and implement the WiMAX-specific parts on top
> of that. The other option would be to replace the EAPOL state machine
> implementation and the related interfaces, i.e., eapol_sm.c (and also
> ieee802_1x.c in case of hostapd). I'm aware of at least couple of
> designs that have done something along these lines for WiMAX use.

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

> The interface from IEEE 802.1X/EAPOL state machines is hardcoded, but
> the implementation of the state machine can be modified. Which way to go
> here would depend on the design used in rest of the software that is
> used for WiMAX support.

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.
But it seems not enough for my idealism.
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.

[deleted...]

> So far, all the WiMAX changes for hostapd/wpa_supplicant has been done
> in quite closed projects and there is unfortunately no publicly
> available source code for this as far as I know. I would be interested
> in helping to make wpa_supplicant/hostapd more suitable for this kind of
> use if someone is willing to do this openly (i.e., end results would be
> open sourced). I don't have any WiMAX hardware/drivers, so I haven't had
> much personal need or interest in working on this area, but that can be
> easily changed by making such things available ;-).

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 ;-)
My competior's product ( the same solution ) is also available on market in
North America currently.

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.
I'd like to contribute some patch like EAPOL overriding but it depends how
much free time I have.
But it depends on if you accept this kind of idea.

-- 
Best regards,
Macpaul Lin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20070326/315413b7/attachment.htm