<br>> Jouni Malinen wrote:<br><br>[deleted..]<br><br>> Yes, WiMAX uses its own mechanism for tunneling EAP authentication<br>> instead of using IEEE 802.1X like IEEE 802.11 is.<br><br>[deleted..]<br><br>> > Is there any way to disable or strip EAPOL header off to make
<br>> > wpa_supplicant/hostapd support some WiMAX sulotion's authentication process?<br>> > Is any state machine or RX handling function need to be modified since it<br>> > seems EAPOL is hard implemented into the core of wpa_supplicant/hostapd.
<br><br>> In general, there are two options for using code from<br>> wpa_supplicant/hostapd with WiMAX. One option is to just use the EAP<br>> server/peer implementation and implement the WiMAX-specific parts on top
<br>> of that. The other option would be to replace the EAPOL state machine<br>> implementation and the related interfaces, i.e., eapol_sm.c (and also<br>> ieee802_1x.c in case of hostapd). I'm aware of at least couple of
<br>> designs that have done something along these lines for WiMAX use.<br><br>Actually, I've already traced the eapol_sm.c before receving the detail information from you ;).<br>I just wondering if there is any way to change the behavior of state machine from driver interface?
<br>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.
<br><br>> The interface from IEEE 802.1X/EAPOL state machines is hardcoded, but<br>> the implementation of the state machine can be modified. Which way to go<br>> here would depend on the design used in rest of the software that is
<br>> used for WiMAX support.<br><br>Yes, Yes. Since there are so many different WiMAX (802.16e) solutions, Intel, Sequence, Runcom, Beceem.<br>It's hard to make wpa_supplicant be suitable for each implementatoin.<br>
I can do some hardcoded modify to made wpa_supplicant to adapt to the solution that I'm working on.<br>But it seems not enough for my idealism. <br>That's why I'm looking for the core developement team's help to made the supplicant can be adaptable to other technologies.
<br>For example, for the solution I'm working on, replace EAPOL with vendor depented protocol (control command) is enought.<br>If EAPOL can be repleaced with other intermediate protocol as easy as runtime parameters or compile-time options,
<br>then the integration to other technology can be more easier and the code can be more reusable.<br><br>[deleted...]<br><br>> So far, all the WiMAX changes for hostapd/wpa_supplicant has been done<br>> in quite closed projects and there is unfortunately no publicly
<br>> available source code for this as far as I know. I would be interested<br>> in helping to make wpa_supplicant/hostapd more suitable for this kind of<br>> use if someone is willing to do this openly (i.e., end results would be
<br>> open sourced). I don't have any WiMAX hardware/drivers, so I haven't had<br>> much personal need or interest in working on this area, but that can be<br>> easily changed by making such things available ;-).
<br><br>Hmm, I'm very happy to do it so but since I'm working for my company ;p<br>It depends on how the source of linux driver and control interface can be released.<br>It seems both the driver and the interface remains proprietary currently.
<br>However, the linux driver and control interface of the solution I'm working on can be reverse engineered easily I think ;-)<br>My competior's product ( the same solution ) is also available on market in North America currently.
<br><br>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.<br>I'd like to contribute some patch like EAPOL overriding but it depends how much free time I have.
<br>But it depends on if you accept this kind of idea.<br><br>-- <br>Best regards,<br>Macpaul Lin