Bug 455498 - NM misdetects encryption type, insists on using incorrect encryption, fails to connect
NM misdetects encryption type, insists on using incorrect encryption, fails t...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
All Linux
low Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-15 14:57 EDT by Charles R. Anderson
Modified: 2008-10-21 08:56 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-21 08:56:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
messages (14.95 KB, text/plain)
2008-07-15 15:03 EDT, Charles R. Anderson
no flags Details
wpa_supplicant.log (2.64 KB, text/plain)
2008-07-15 15:04 EDT, Charles R. Anderson
no flags Details
iwlist scanning output (4.51 KB, text/plain)
2008-07-15 15:04 EDT, Charles R. Anderson
no flags Details

  None (edit)
Description Charles R. Anderson 2008-07-15 14:57:22 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):
NetworkManager-0.7.0-0.9.4.svn3675.fc9.x86_64
wpa_supplicant-0.6.3-6.fc9.x86_64
kernel-2.6.25.9-76.fc9.x86_64

How reproducible:
always

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
  
Actual results:

wlan0     Scan completed :
          Cell 01 - Address: 00:90:4C:91:00:01
                    ESSID:"Doubletree RG"
                    Mode:Master
                    Channel:6
                    Frequency:2.437 GHz (Channel 6)
                    Quality=100/100  Signal level:-50 dBm  Noise level=-94 dBm
                    Encryption key:off
                    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
                    Extra:tsf=00000000f32a0184

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
dhclient wlan0

Expected results:

NM shouldn't insist on using encrypted modes like WEP or WPA/WPA2 when iwlist
says "Encryption key:off".

Additional info:
Lenovo T61 w/Intel 4965 wireless.
Comment 1 Charles R. Anderson 2008-07-15 14:58:45 EDT
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   
          Encryption key:off
          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
Comment 2 Charles R. Anderson 2008-07-15 15:03:58 EDT
Created attachment 311869 [details]
messages
Comment 3 Charles R. Anderson 2008-07-15 15:04:18 EDT
Created attachment 311870 [details]
wpa_supplicant.log
Comment 4 Charles R. Anderson 2008-07-15 15:04:41 EDT
Created attachment 311871 [details]
iwlist scanning output
Comment 5 Dan Williams 2008-07-16 12:18:01 EDT
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.
Comment 6 Dan Williams 2008-10-20 10:49:16 EDT
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.
Comment 7 Charles R. Anderson 2008-10-20 13:53:55 EDT
I haven't seen this happen again...
Comment 8 Dan Williams 2008-10-21 08:56:54 EDT
Ok, thanks!

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