#9936 NORM Not Tri: First WPA2 association (TKIP/AES) always fails, retries succeed
Zarro Boogs per Child
bugtracker at laptop.org
Sat Jan 2 18:56:25 EST 2010
#9936: First WPA2 association (TKIP/AES) always fails, retries succeed
------------------------------------+---------------------------------------
Reporter: cabalde | Owner: martin.langhoff
Type: defect | Status: new
Priority: normal | Milestone: Not Triaged
Component: not assigned | Version: 1.0 Software Build 802
Resolution: | Keywords:
Next_action: never set | Verified: 0
Deployment_affected: | Blockedby:
Blocking: |
------------------------------------+---------------------------------------
Comment(by martin.langhoff):
dsd - thanks for chiming in. The Ceibal team is reporting that with their
APs, WPA always succeeds and WPA2 always fails _on the first connection
attempt_ (and succeeds in subsequent attempts).
I am hoping to get a listing of model/chipset from them. If this is not
AP-specific, it may have to do with memory initialization in supplicant,
the driver or the firmware.
Timing-related WPA/WPA2 issues probably remain, but those are hard to
repro. This seems to be reproduceable 100%, and more clearly measurable
with the patched NM I prepared (with your dbus/dhcp fix in place and fixed
logging).
One oddity is that wpa_supplicant is always running in debug mode, even in
"normal" operation, due to a bug in NM. It just writes the debug log to
/dev/null.
If we think this can be caused by timing issues (wpa_supplicant being too
slow), I can prep a NM that actually disables debugging in wpa_supp in
normal operation. But Ceibal's report doesn't sound like a timing issue.
I left this debug-to-devnull undisturbed so far out of respect towards odd
timing issues. Some bugs -- inc the ones you mention -- indicate that
enabling debugging increases our success rate...
--
Ticket URL: <http://dev.laptop.org/ticket/9936#comment:6>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list