Thank you Brian, I'm new here and forgive my English!
For the bug:
I recompiled wpa_supplicant as suggested in the Bug #207447 and I appreciated a significant improvement in stability of the connection. Anyway: I found out that it make no difference if I insert an usleep() in the wpa.c code. I tried with low values (50-100) and long values (100000-1000000).
With the recompilation I can mostly get connected: when I can not I have to renice the process to -19
An issue about wpa.c:
I use the 0.6.9 version of wpa_supplicant and in the wpa.c code I put the usleep() in the line 996, after:
if (wpa_supplicant_send_4_of_4(sm, sm->bssid, key, ver, key_info,
NULL, 0, &sm->ptk))
return;
this because the code was a little bit different from what explained by Christof Kaser in the above mentioned bug
is it correct?I will investigate...
Thank you Brian, I'm new here and forgive my English!
For the bug: _send_4_ of_4(sm, sm->bssid, key, ver, key_info,
I recompiled wpa_supplicant as suggested in the Bug #207447 and I appreciated a significant improvement in stability of the connection. Anyway: I found out that it make no difference if I insert an usleep() in the wpa.c code. I tried with low values (50-100) and long values (100000-1000000).
With the recompilation I can mostly get connected: when I can not I have to renice the process to -19
An issue about wpa.c:
I use the 0.6.9 version of wpa_supplicant and in the wpa.c code I put the usleep() in the line 996, after:
if (wpa_supplicant
NULL, 0, &sm->ptk))
return;
this because the code was a little bit different from what explained by Christof Kaser in the above mentioned bug
is it correct?I will investigate...