<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span><br></span></div><div><span>Hi Jouni,</span></div><div><span><br></span></div><div><span>We tried in a different laptop and the problem with the </span>unexpected disconnection event went away, so we believe this was an issue particular to our first laptop.</div><div><br></div><div>Regarding the lack of entropy, we are using laptops, however we have scripted the connection process and run these scripts in batch mode without user interaction. Could this be the reason for the lack of entropy ? In that case would there be the possibility of configuring wpa_supplicant to require a lower level of entropy ?</div><div><br></div><div>Best Regards</div><div><br></div><div>Daniel</div><div><br></div><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "><div style="font-size: 12pt;
font-family: 'times new roman', 'new york', times, serif; "><font size="2" face="Arial"><hr size="1"><b><span style="font-weight:bold;">De:</span></b> Jouni Malinen <j@w1.fi><br><b><span style="font-weight: bold;">Para:</span></b> "hostap@lists.shmoo.com" <hostap@lists.shmoo.com><br><b><span style="font-weight: bold;">Enviado:</span></b> domingo 2 de octubre de 2011 17:38<br><b><span style="font-weight: bold;">Asunto:</span></b> Re: Help understanding WPS trace<br></font><br>On Fri, Sep 30, 2011 at 10:36:46AM +0100, Dani Camps wrote:<br>> The, in our opinion, problem is a too high delay between the time when the WPS phase completes and the time when the P2P Client associates to the P2P GO and starts the 4-way key exchange. If you look at the p2p_cli.log, you can see in the following line when the P2P Client starts trying to authenticate for the first time with the P2P GO after WPS completes:<br>> <br>> 1317289042.619717: wlan1:
State: DISCONNECTED -> AUTHENTICATING<br>> <br>> <br>> Then, the P2P Client only proceeds with the Association and Key exchange 8 seconds later, you can see it in this line.<br>> <br>> 1317289050.672501: wlan1: State: AUTHENTICATING -> ASSOCIATING<br><br>There seems to be number of issues on the client side.. It looks like<br>something is generating unexpected disconnection events and that makes<br>wpa_supplicant confused. Are you sure there is no other program trying<br>to control the wireless interface (like Network Manager)?<br><br>It is unclear what happens with the first authentication attempt at<br>1317289042.618844.. It is more or less immediately followed by a<br>Deauthentication notification at 1317289042.619221 which, I guess, could<br>be from the previous association. However, it could also be caused by<br>something else in the system requesting the WLAN card to disconnect at<br>that point. This results in some apparent
confusion in wpa_supplicant<br>when trying to process the next scan results at 1317289045.666867. This<br>should have request a new connection, but it assumed that the connection<br>is already in process from the previous attempt. This costs couple of<br>seconds and an extra scan.<br><br>> This is not something that happens always, many times we observe that the transition between the first Authentication and the Association and Key exchange occurs in around 3 seconds.<br><br>This should not really take much time.. The scan operation can take a<br>few seconds, but it should be possible to optimize that to only use the<br>expect channel as is done for the WPS provisioning step. I'm not sure<br>why that did not happen here, though. The unexpected disconnection event<br>seems to be causing most of the issues here, though. It would be nice to<br>be able to reproduce this at will to enable some experimentation..<br><br>> Digging a bit further the
problem seems to be here in the p2p_cli.log:<br>> <br>> 1317289047.619871: wlan1: SME: Authentication timeout<br>> 1317289047.619879: wpa_driver_nl80211_deauthenticate(addr=00:1b:11:c5:56:a4 reason_code=3)<br>> 1317289047.619933: nl80211: MLME command failed: ret=-107 (Transport endpoint is not connected)<br>> <br>> For some reason the P2P Client does not proceed with the Reassociation after the first Authentication, then an internal timeout in the P2P Client occurs and the P2P Client cancels its current authentication and so it starts all the process of scanning, authentication and association which results in the mentioned delay. We do not understand why the P2P Client gets hung up after the first Authentication until the timeout occurs. Is this a bug, or is there a reason for the behavior ?<br><br>Either something else in the system caused the driver to disconnect or<br>the timing of the disconnection event after the WPS
provisioning step is<br>perfect for confusing the state between wpa_supplicant and cfg80211.<br>Anyway, there seems to be a bug somewhere since it should not have taken<br>that long to recover from the issue.<br><br>In addition to the client side issues, there is also one issue on the GO<br>that adds more delay to the connection. It looks like there is not<br>enough entropy available for random number generation (is this an<br>embedded device with no keyboard and mouse?) and that results in the<br>first 4-way handshake after the WPS provisioning getting rejected while<br>more entropy is being collected to allow more secure key generation.<br><br>> Please let us know if anymore information would be helpful to understand the problem. We can send you the wireshark capture if you think is required.<br><br>It could be useful to see what the debug output from mac80211/cfg80211<br>looks like in dmesg output on the client since the client side issues<br>seem
to be very much related to the association state mismatch and<br>unexpected processing of disconnection events.<br><br>-- <br>Jouni Malinen PGP id EFC895FA<br>_______________________________________________<br>HostAP mailing list<br><a ymailto="mailto:HostAP@lists.shmoo.com" href="mailto:HostAP@lists.shmoo.com">HostAP@lists.shmoo.com</a><br><a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br><br><br></div></div></div></body></html>