Bug 439615 - NetworkManager wifi fails on logout/login
Summary: NetworkManager wifi fails on logout/login
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-29 17:06 UTC by Emil Librea III
Modified: 2008-04-05 20:02 UTC (History)
5 users (show)

Fixed In Version: 2.6.24.4-64.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-03 19:42:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Message log extract (9.38 KB, text/plain)
2008-03-31 17:19 UTC, Emil Librea III
no flags Details
var/log/messages output for failing wireless connect (8.01 KB, text/plain)
2008-03-31 19:37 UTC, Stephen Rowles
no flags Details

Description Emil Librea III 2008-03-29 17:06:04 UTC
Description of problem:
NetworkManager fails to associate to WEP access point after logging out and then
back in.

Version-Release number of selected component (if applicable):
NetworkManager.i386 1:0.7.0-0.6.7.svn3235
kernel.i686 2.6.24.3-50.fc8

How reproducible:
On a fresh boot, login and then enter your keyring password so that NM can
access the network secret. Association is successful.

Log out and then log back in. NM repeatedly asks for keyring password and fails
to associate to the WEP access point.

Steps to Reproduce:
1. See above
2.
3.
  
Actual results: (Relevant extracts from the message log)

On fresh boot:

Mar 29 23:45:49 oinxoinx NetworkManager: <info>  Activation (wlan0/wireless):
access point 'Auto OinkOink' has security, but secrets are required.
Mar 29 23:45:56 oinxoinx NetworkManager: Missing or invalid key management
Mar 29 23:45:56 oinxoinx NetworkManager: <info>  Activation (wlan0/wireless):
connection 'Auto OinkOink' has security, and secrets exist.  No new secrets needed.
Mar 29 23:45:56 oinxoinx NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) complete.
Mar 29 23:46:01 oinxoinx NetworkManager: <info>  Activation (wlan0) Stage 3 of 5
(IP Configure Start) complete.
Mar 29 23:46:02 oinxoinx NetworkManager: <info>  Activation (wlan0) Stage 4 of 5
(IP Configure Get) complete.
Mar 29 23:46:03 oinxoinx NetworkManager: <info>  Activation (wlan0) Stage 5 of 5
(IP Configure Commit) complete.

After logout/login:

Mar 29 23:57:52 oinxoinx NetworkManager: <info>  Activation (wlan0/wireless):
access point 'Auto OinkOink' has security, but secrets are required.
Mar 29 23:57:57 oinxoinx NetworkManager: Missing or invalid key management
Mar 29 23:57:57 oinxoinx NetworkManager: <info>  Activation (wlan0/wireless):
connection 'Auto OinkOink' has security, and secrets exist.  No new secrets needed.
Mar 29 23:57:57 oinxoinx NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
(Device Configure) complete.
Mar 29 23:58:22 oinxoinx NetworkManager: <info>  Activation (wlan0/wireless):
association took too long, asking for new key.
Mar 29 23:58:24 oinxoinx NetworkManager: <WARN>  get_secrets_cb(): Couldn't get
connection secrets: applet.c.3300 (get_secrets_dialog_response_cb): canceled.
Mar 29 23:58:24 oinxoinx NetworkManager: <info>  Activation (wlan0) failed for
access point (OinkOink)

After rebooting, I am able to access the wireless network again.

Expected results:
Able to access wireless network even after repeated login attempts.

Additional info:

Comment 1 Dan Williams 2008-03-31 16:35:35 UTC
does it work if you rmmod the driver module for your wireless card while logged
out, then modprobe it and log in again?  this would indicate a driver problem.

What wireless card/hardware do you have?

Comment 2 Emil Librea III 2008-03-31 17:10:16 UTC
using an Intel 3945abg card on an Acer Aspire 5583WXMi laptop

sorry, don't know what you mean by 'rmmod while logged out' (fairly new to linux).

in any case, have tried rmmod iwl3945, which successfully kills the connection
(while logged in to X from a root terminal). After a few seconds, however, the
connection comes back on (don't need to modprobe) and NM picks up the WEP access
point from where it left off.

i've also realized that rmmoding iwl3945 is the best way to restart NM so that
it successfully connects after I log off then log back in. Before I reported
this issue, i had to kill NM, NMDispatcher and wpa-supp then restart NM and
enter my keyring password to get a successful connection.

hope this helps. if not, please advise exact procedure you want me to do. thanks

Comment 3 Emil Librea III 2008-03-31 17:19:03 UTC
Created attachment 299745 [details]
Message log extract

Comment 4 Emil Librea III 2008-03-31 17:19:47 UTC
Message log extract attached right after i execute rmmod iwl3945

Comment 5 Dan Williams 2008-03-31 18:17:00 UTC
Another iwlwifi one for you John...  thoughts on how to further debug?  Maybe
hardware vs. software scanning with disable_hw_scan=1 or something?  When an
rmmod fixes an issue with NM, I usually find there are driver issues...

Comment 6 Stephen Rowles 2008-03-31 19:37:20 UTC
Created attachment 299753 [details]
var/log/messages output for failing wireless connect

Comment 7 Stephen Rowles 2008-03-31 19:38:19 UTC
I also suffer from this problem, it is very frustrating as my laptop has 2
logins and this problem means that wireless will only work for the first time
login after boot.

First association with access point works fine. After logout NetworkManager will
not longer connect until reboot. I have attached the output from
/var/log/messages which shows the cycle that NetworkManager / wpa_supplicant
gets into.

I get the following in dmesg output repeated lots of times:

wlan0: RX disassociation from 00:30:bd:fb:29:e1 (reason=7)

I am happy to try and get any debugging info required if you can provide
instructions :)

I can confirm that rmmod from a root console after logging out means that the
wireless will connect correctly on next login.

System Details:

uname -a
Linux mini-manicminer 2.6.24.3-50.fc8 #1 SMP Thu Mar 20 14:47:10 EDT 2008 i686
i686 i386 GNU/Linux

Network card:
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux,
1.2.26kds
iwl3945: Copyright(c) 2003-2008 Intel Corporation

Laptop: Acer 5920

Firmware:
rpm -qa |grep -i iwl
iwl3945-firmware-2.14.1.5-2

Network Manager:
NetworkManager-0.7.0-0.6.7.svn3235.fc8

Comment 8 John W. Linville 2008-04-01 13:43:54 UTC
Do you have a line like this in /etc/modprobe.conf?

   options iwl3945 disable_hw_scan=1

Could you either add it or remove it and try again with/without it to see what 
difference it may make?

Comment 9 Emil Librea III 2008-04-01 13:51:50 UTC
tnx - adding the line above to modprobe.conf fixes the problem.

is this a fix or a temporary workaround?

Comment 10 John W. Linville 2008-04-01 14:54:39 UTC
I would like to believe it is the latter.  Let's hope so...

Comment 11 Stephen Rowles 2008-04-01 18:46:07 UTC
I added:

options iwl3945 disable_hw_scan=1

to /etc/modules.conf

This appears to be a successful workaround, I hope this helps identifying what
is wrong with the hardware based scanning.

Cheers.

Comment 12 Stephen Rowles 2008-04-02 11:23:25 UTC
Further note, with the disable_hw_scan set wireless also successfully works
after suspend / wakeup cycle.

Comment 13 John W. Linville 2008-04-02 13:43:17 UTC
Sounds like hardware scan support (which only iwl3945 and iwl4965 use) is 
broken again...

Comment 14 Emil Librea III 2008-04-03 19:07:19 UTC
I have just updated to kernel 2.6.24.4-64.fc8, removed the line

options iwl3946 disable_hw_scan=1

from /etc/modprobe.conf

and looks like the update has fixed the problem. 

Please advise if you need more information.


Comment 15 John W. Linville 2008-04-03 19:42:37 UTC
Ah, thanks for the report!

Comment 16 Stephen Rowles 2008-04-05 20:02:32 UTC
I also tested today with the hw_scan line removed and the problem is NOT fixed
for me :)

[steve@mini-manicminer ~]$ uname -a
Linux mini-manicminer 2.6.24.4-64.fc8 #1 SMP Sat Mar 29 09:54:46 EDT 2008 i686
i686 i386 GNU/Linux

I get stuck in the same /var/log/messages cycle as in my attached log extract.
Adding the line back in again and everything works.

so for me this is not fixed.


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