So it looks like eap_peer_sm_step() is returning after processing an EAP request without setting either eap_ctx.eapResp or eap_ctx.eapSuccess, so the handshake just hangs ... but I'm not sure why that would happen or what it should be doing.
On Sun, Oct 03, 2010 at 11:18:40PM -0400, Paul Donohue wrote: > Forgot to mention the wimaxd output, which looks relevant: > > # wimaxd -d -i wmx0 > Enter Command: > q - Quit AppSrv > t - Trace ReInit (ReLoads Registry Values) > u - uplink(Apdo uplink event > h - Help > d - Toggle driver messages to display - debug & internal only > > > AppSrv is ready ! > Act_FullRestart! > Act_DriverDeviceStatus - DRIVER_UP > CTRL-EVENT-EAP-STARTED EAP authentication started > Sending EapResponse. Data size: 49 > CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13 > CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected > Sending EapResponse. Data size: 10 > > On Sun, Oct 03, 2010 at 11:14:45PM -0400, Paul Donohue wrote: > > The attached patch replaces the last one and has another additional fix. > > > > I'm getting a bit further - the connect procedure starts, but now I seem to > > be failing during authentication. I'm not entirely sure I understand what > > is supposed to be happening at this point, so any debugging suggestions > > would be greatly appreciated. Inaky, it might help if you could send me an > > example of what a successful connection is supposed to look like in > > wimaxd.log. > > > > The relevant lines in wimaxd.log are: > _______________________________________________ > wimax mailing list > [email protected] > http://lists.linuxwimax.org/listinfo/wimax > _______________________________________________ wimax mailing list [email protected] http://lists.linuxwimax.org/listinfo/wimax
