>OK. If you are only using fixed configuration (no user interaction<br>>during authentication) and do not use the double EAP mode defined in<br>>802.16e, this may be enough.<br><br>Yes, for now i'm using fixed configuration. I'm authenticating with TTLS/MD5 and TTLS/MSCHAPV2. The information for the second TTLS phase (MD5 / MSCHAPv2) is fixed in the configuration files of wpa supplicant. <br>
<br>>I would describe option (1) a bit differently: integrate the EAP peer<br> > functionality from wpa_supplicant (not full wpa_supplicant) to SS since<br> > WiMax does not really use much of the other functionality from<br>
> wpa_supplicant. Or well, the configuration parser could probably be<br> > shared, too.<br><br>Yes, exactly this. I'd need to "clean" the wpa supplicant from other functionality.<br>This approach seem be more complex to do, then I stay with the second option.<br>
<br> > I do not have good enough understanding of the particular project to say<br> > what would be best option here. I understand that option (2) may look<br> > like the easiest solution for this case. However, I'm looking this from<br>
> a bit different view point since I would prefer to make sure that the<br> > interfaces in wpa_supplicant provide functionality that would fit well<br> > into any WiMax design in addition to 802.11-based solutions.<br>
<br>I only need wpa supplicant to authenticate and send me the msk. After the success (or fail), the job of wpa supplicant is done. After that, my Ss software will handle all the subsequent phases. <br>The wpa supplicant dont need to know about wimax at all. It only create (and manage) the eap packets for me. <br>
<br> > Anyway, I would suggest at least taking a quick look at the EAP peer<br> > example (use of EAP peer functionality from wpa_supplicant as a library<br> > for another program) that is available in the Git repository:<br>
> <a href="http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=eap_example;hb=HEAD">http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=eap_example;hb=HEAD</a><br> > I wrote this example especially with non-802.1X uses in mind and WiMax<br>
> is mentioned as one example case. The example code includes minimal<br> > setup for using EAP peer functionality and this could be used linked<br> > together with rest of the SS software to implement PMK EAP.<br>
<br>I'll see this. Thanks.....<br><br>My Ss software already handle all the PKM stuff.<br><br> > Unfortunately, I do not have any WiMax hardware to play with, so I<br> > haven't experimented with what exactly would be needed in wpa_supplicant<br>
> to make it fit well with WiMax design. The EAP peer example should work<br> > fine in this type of use, but it would also be interesting to see a more<br> > complete reference design for WiMax authentication to be added in the<br>
> future.<br> <br>Ok, Note that all the wimax protocol is already implemented in my software. I have a massage (EAP_DATA in my software) where in send the eap packet as a payload and the rest is already implemented. I only need to create the eap packets, and i'm using wpa supplicant for that. The subsequent wimax stuff is already done, as i said.<br>
<br>>I added Marcel to the cc list because he's poked around trying to get<br>>wpa_supplicant working with WiMAX and ran into some issues. Would be<br>>good to get some dialog here so we can nail the issues, some of which<br>
>stem from lack of flexibility in the D-Bus control interface. That can<br>>be fixed, but what general supplicant issues were you having, Marcel,<br>>that you might want to make Jouni aware of?<br><br>Cool, any help is welcome. :-)<br>
<br><div><span class="gmail_quote">On 4/15/08, <b class="gmail_sendername">Dan Williams</b> <<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 2008-04-15 at 20:25 +0300, Jouni Malinen wrote:<br> > On Mon, Apr 14, 2008 at 04:45:54PM -0300, Douglas Diniz wrote:<br> ><br> > > The interface is very simple. I just receive a eap packet from SS software<br>
> > and send it to wpa supplicant. Just it. I only check the eap message to<br> > > search for a eap success. If the message is a success I expect that the next<br> > > message from wpa supplicant is the msk. I dont need any eap state machine<br>
> > here (I hope).<br> ><br> > OK. If you are only using fixed configuration (no user interaction<br> > during authentication) and do not use the double EAP mode defined in<br> > 802.16e, this may be enough.<br>
><br> > > I had two options:<br> > ><br> > > 1-) Incorporate the wpa supplicant to Ss software, creating a function<br> > > interface to the Ss's software. This need a lot of time.<br> > ><br>
> > 2-) Create this module to receive messages from SS and send to wpa<br> > > supplicant.<br> ><br> > I would describe option (1) a bit differently: integrate the EAP peer<br> > functionality from wpa_supplicant (not full wpa_supplicant) to SS since<br>
> WiMax does not really use much of the other functionality from<br> > wpa_supplicant. Or well, the configuration parser could probably be<br> > shared, too.<br> ><br> > > In fact i'm installing wpa supplicant in SS's host and send the messages<br>
> > over localhost. So, the interface is secure.<br> > ><br> > > In my place, what you would do?<br> ><br> > I do not have good enough understanding of the particular project to say<br> > what would be best option here. I understand that option (2) may look<br>
> like the easiest solution for this case. However, I'm looking this from<br> > a bit different view point since I would prefer to make sure that the<br> > interfaces in wpa_supplicant provide functionality that would fit well<br>
> into any WiMax design in addition to 802.11-based solutions.<br> ><br> > Anyway, I would suggest at least taking a quick look at the EAP peer<br> > example (use of EAP peer functionality from wpa_supplicant as a library<br>
> for another program) that is available in the Git repository:<br> > <a href="http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=eap_example;hb=HEAD">http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=eap_example;hb=HEAD</a><br>
><br> > I wrote this example especially with non-802.1X uses in mind and WiMax<br> > is mentioned as one example case. The example code includes minimal<br> > setup for using EAP peer functionality and this could be used linked<br>
> together with rest of the SS software to implement PMK EAP.<br> ><br> > Unfortunately, I do not have any WiMax hardware to play with, so I<br> > haven't experimented with what exactly would be needed in wpa_supplicant<br>
> to make it fit well with WiMax design. The EAP peer example should work<br> > fine in this type of use, but it would also be interesting to see a more<br> > complete reference design for WiMax authentication to be added in the<br>
> future.<br> <br> <br>I added Marcel to the cc list because he's poked around trying to get<br> wpa_supplicant working with WiMAX and ran into some issues. Would be<br> good to get some dialog here so we can nail the issues, some of which<br>
stem from lack of flexibility in the D-Bus control interface. That can<br> be fixed, but what general supplicant issues were you having, Marcel,<br> that you might want to make Jouni aware of?<br> <br><br> Dan<br> <br><br>
<br> _______________________________________________<br> HostAP mailing list<br> <a href="mailto:HostAP@lists.shmoo.com">HostAP@lists.shmoo.com</a><br> <a href="http://lists.shmoo.com/mailman/listinfo/hostap">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
</blockquote></div><br>