This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 245043 - wpa_supplicant regularly gets into a negotiate/clear loop.
wpa_supplicant regularly gets into a negotiate/clear loop.
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: wpa_supplicant (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-20 13:51 EDT by Wolfgang Rupprecht
Modified: 2008-08-02 19:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-25 00:12:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
wpa_supplicant trace file generated with "-d" flag. (53.00 KB, text/plain)
2007-06-20 13:51 EDT, Wolfgang Rupprecht
no flags Details

  None (edit)
Description Wolfgang Rupprecht 2007-06-20 13:51:07 EDT
Description of problem:

wpa_supplicant will sometimes get in a loop where it endlessly tries to bring up
and tears down the associations and negotiated keys.  Once in this mode it will
tend to stay until restarted via "service wap_supplicant restart"

I'll attach a trace that shows this looping captured via:

"wpa_supplicant -d -c /etc/wpa_supplicant/wpa_supplicant.conf -iath0 -Dwext"

Some related wpa_supplicant issues: 

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244029
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197319

Version-Release number of selected component (if applicable):
wpa_supplicant-0.5.7-3.fc7

How reproducible:
It happens regularly with my ubiquiti atheros-based card.  The easiest way
to reproduce here is to start wpa_supplicant in initscript timeslot "9", just
before the network.  Under fc6 this method of running wpa_supplicant worked
fine.  On F7 it loops with 100% regularity.

Steps to Reproduce:
1. modify wpa_startup script as per
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=156873
2. reboot
3. log in as root
4. run wpa_gui and watch the SCANNING/ASSOCIATING/DISCONNECTED msgs flash on and
off with the keys negotiated and cleared in quick succession.
  
Actual results:
wpa_supplicant negotiates and clears the keys in a ~10 second loop.

Expected results:
wpa_supplicant should negotiate the keys and then keep them.

Additional info:

From the attached logs it looks like wpa_supplicant is under the impression 
that the radio already is setup and associated "Already associated with the
selected AP."  and the code seems to not want to write to the radio with 
data it thinks is already there.  In actuality the radio isn't associated and
nas no valid keys loaded.  It looks like somehow the radio's state and
wpa_supplicants state has diverged.

I have also ested the most recent test version of wpa_supplicant (0.6.0)  and it 
has similar loops.

Note: I wasn't sure if the actual psk keys show up in the trace.  If they do
please someone note that here.  That will keep others from being surprised by 
posting wpa_supplicant traces.
Comment 1 Wolfgang Rupprecht 2007-06-20 13:51:08 EDT
Created attachment 157483 [details]
wpa_supplicant trace file generated with "-d" flag.
Comment 2 Dan Williams 2008-01-16 16:56:34 EST
Can you try with a later version of the madwifi driver please?  This looks more
like a driver bug than something in wpa_supplicant.  At least 0.9.3.3 or later.
 Thanks!
Comment 3 Brian Powell 2008-04-25 00:12:36 EDT
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "CLOSED INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.

Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.

Note You need to log in before you can comment on or make changes to this bug.