Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 455498

Summary: NM misdetects encryption type, insists on using incorrect encryption, fails to connect
Product: [Fedora] Fedora Reporter: Charles R. Anderson <cra>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 9CC: dcbw, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-21 12:56:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
messages
none
wpa_supplicant.log
none
iwlist scanning output none

Description Charles R. Anderson 2008-07-15 18:57:22 UTC
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 18:58:45 UTC
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 19:03:58 UTC
Created attachment 311869 [details]
messages

Comment 3 Charles R. Anderson 2008-07-15 19:04:18 UTC
Created attachment 311870 [details]
wpa_supplicant.log

Comment 4 Charles R. Anderson 2008-07-15 19:04:41 UTC
Created attachment 311871 [details]
iwlist scanning output

Comment 5 Dan Williams 2008-07-16 16:18:01 UTC
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 14:49:16 UTC
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 17:53:55 UTC
I haven't seen this happen again...

Comment 8 Dan Williams 2008-10-21 12:56:54 UTC
Ok, thanks!