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 > wimax at linuxwimax.org > http://lists.linuxwimax.org/listinfo/wimax >
