Red Hat Bugzilla – Bug 455498
NM misdetects encryption type, insists on using incorrect encryption, fails to connect
Last modified: 2008-10-21 08:56:54 EDT
Description of problem:
NM sometimes detects open (unencrypted) networks as WPA, and insists on
requiring a WPA or WEP passphrase. This fails to work of course, because the
network is really unencrypted.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. go where there is an open wifi hotspot
2. look in nm-applet list, note "encrypted" icon next to ESSID
3. try to connect, nm-applet asks for passphrase, fails to connect to open network
wlan0 Scan completed :
Cell 01 - Address: 00:90:4C:91:00:01
Frequency:2.437 GHz (Channel 6)
Quality=100/100 Signal level:-50 dBm Noise level=-94 dBm
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
12 Mb/s; 48 Mb/s
NM shows "encrypted" icon in list of wireless networks next to the "Doubletree
RG" ESSID and then pops up with a WPA/WPA2 dialog when trying to connect to it,
which fails of course. Running the following allows to connect manually:
service NetworkManager stop
iwconfig wlan0 essid "Doubletree RG"
iwconfig wlan0 enc off
ifconfig wlan0 up
NM shouldn't insist on using encrypted modes like WEP or WPA/WPA2 when iwlist
says "Encryption key:off".
Lenovo T61 w/Intel 4965 wireless.
iwconfig output when connected manually:
wlan0 IEEE 802.11 ESSID:"Doubletree RG"
Mode:Managed Frequency:2.437 GHz Access Point: 00:90:4C:91:00:01
Bit Rate=54 Mb/s Tx-Power=14 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Link Quality=100/100 Signal level:-42 dBm Noise level=-94 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Created attachment 311869 [details]
Created attachment 311870 [details]
Created attachment 311871 [details]
iwlist scanning output
I think there are a few reference counting issues in the applet that need to be
fixed; it's confusing APs when NM gets restarted and the applet doesn't. The
way to determine this is to check /usr/bin/nm-tool to see what NM thinks and
then compare that to what the applet thinks. If they differ, that's what the
issue is. If they don't, then it's NM's problem and not the applets. After
doing an nm-tool, try 'killall -TERM nm-applet; /usr/bin/nm-applet &' and see if
it shows up correctly? That would confirm it.
Is this still an issue with latest NM? I've fixed the refcounting issues I mentioned in comment 5 and haven't seen this sort of thing for a while.
I haven't seen this happen again...