Bug 565926 - [enh] New automatic wireless connections should default to "IPv6 Ignored"
Summary: [enh] New automatic wireless connections should default to "IPv6 Ignored"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 569192 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-02-16 17:50 UTC by Tom London
Modified: 2010-06-15 16:01 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-06-15 16:01:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tom London 2010-02-16 17:50:20 UTC
Description of problem:
NetworkManager-0.8.0-0.4.git20100211.fc13.x86_64 (and probably earlier) does not complete connecting to my enterprise/corporate wireless LAN: the "system tray" icon keeps spinning (with both green lights lit), and I have no IPv4 address assigned.

The network uses WPA2, PEAP and MSCHAPv2.

This "failure" happens every time.

Here is a log from /var/log/messages generated by me manually selecting the wireless network:

Feb 16 09:46:02 tlondon NetworkManager: <info>  Activation (wlan0) starting connection 'Auto OBSCURED-SSID'
Feb 16 09:46:02 tlondon NetworkManager: <info>  (wlan0): device state change: 3 -> 4 (reason 0)
Feb 16 09:46:02 tlondon NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Feb 16 09:46:02 tlondon NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Feb 16 09:46:02 tlondon NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Feb 16 09:46:02 tlondon NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Feb 16 09:46:02 tlondon NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Feb 16 09:46:02 tlondon NetworkManager: <info>  (wlan0): device state change: 4 -> 5 (reason 0)
Feb 16 09:46:02 tlondon NetworkManager: <info>  Activation (wlan0/wireless): connection 'Auto OBSCURED-SSID' has security, and secrets exist.  No new secrets needed.
Feb 16 09:46:02 tlondon NetworkManager: <info>  Config: added 'ssid' value 'OBSCURED-SSID'
Feb 16 09:46:02 tlondon NetworkManager: <info>  Config: added 'scan_ssid' value '1'
Feb 16 09:46:02 tlondon NetworkManager: <info>  Config: added 'key_mgmt' value 'WPA-EAP'
Feb 16 09:46:02 tlondon NetworkManager: <info>  Config: added 'password' value '<omitted>'
Feb 16 09:46:02 tlondon NetworkManager: <info>  Config: added 'eap' value 'PEAP'
Feb 16 09:46:02 tlondon NetworkManager: <info>  Config: added 'fragment_size' value '1300'
Feb 16 09:46:02 tlondon NetworkManager: <info>  Config: added 'phase2' value 'auth=MSCHAPV2'
Feb 16 09:46:02 tlondon NetworkManager: <info>  Config: added 'identity' value 'OBSCURED_ID'
Feb 16 09:46:02 tlondon NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Feb 16 09:46:02 tlondon NetworkManager: <info>  (wlan0): supplicant connection state:  scanning -> disconnected
Feb 16 09:46:02 tlondon NetworkManager: <info>  Config: set interface ap_scan to 1
Feb 16 09:46:02 tlondon NetworkManager: <info>  (wlan0): supplicant connection state:  disconnected -> scanning
Feb 16 09:46:03 tlondon NetworkManager: <info>  (wlan0): supplicant connection state:  scanning -> associating
Feb 16 09:46:03 tlondon NetworkManager: <info>  (wlan0): supplicant connection state:  associating -> associated
Feb 16 09:46:07 tlondon NetworkManager: <info>  (wlan0): supplicant connection state:  associated -> 4-way handshake
Feb 16 09:46:07 tlondon NetworkManager: <info>  (wlan0): supplicant connection state:  4-way handshake -> group handshake
Feb 16 09:46:07 tlondon NetworkManager: <info>  (wlan0): supplicant connection state:  group handshake -> completed
Feb 16 09:46:07 tlondon NetworkManager: <info>  Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to wireless network 'OBSCURED_SSID'.
Feb 16 09:46:07 tlondon NetworkManager: <info>  Activation (wlan0) Stage 3 of 5 (IP Configure Start) scheduled.
Feb 16 09:46:07 tlondon NetworkManager: <info>  Activation (wlan0) Stage 3 of 5 (IP Configure Start) started...
Feb 16 09:46:07 tlondon NetworkManager: <info>  (wlan0): device state change: 5 -> 7 (reason 0)
Feb 16 09:46:07 tlondon NetworkManager: Activation (wlan0) Beginning DHCPv4 transaction (timeout in 45 seconds)
Feb 16 09:46:07 tlondon NetworkManager: <info>  dhclient started with pid 9638
Feb 16 09:46:07 tlondon NetworkManager: nm_ip6_manager_begin_addrconf: assertion `NM_IS_IP6_MANAGER (manager)' failed
Feb 16 09:46:07 tlondon NetworkManager: <info>  Activation (wlan0) Stage 3 of 5 (IP Configure Start) complete.
Feb 16 09:46:07 tlondon dhclient[9638]: Internet Systems Consortium DHCP Client 4.1.1
Feb 16 09:46:07 tlondon dhclient[9638]: Copyright 2004-2010 Internet Systems Consortium.
Feb 16 09:46:07 tlondon dhclient[9638]: All rights reserved.
Feb 16 09:46:07 tlondon dhclient[9638]: For info, please visit https://www.isc.org/software/dhcp/
Feb 16 09:46:07 tlondon dhclient[9638]: 
Feb 16 09:46:07 tlondon NetworkManager: DHCPv4: device wlan0 state changed nbi -> preinit
Feb 16 09:46:07 tlondon dhclient[9638]: Listening on LPF/wlan0/00:21:5d:ac:c6:92
Feb 16 09:46:07 tlondon dhclient[9638]: Sending on   LPF/wlan0/00:21:5d:ac:c6:92
Feb 16 09:46:07 tlondon dhclient[9638]: Sending on   Socket/fallback
Feb 16 09:46:07 tlondon dhclient[9638]: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
Feb 16 09:46:12 tlondon dhclient[9638]: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
Feb 16 09:46:12 tlondon dhclient[9638]: DHCPACK from 10.11.14.1
Feb 16 09:46:12 tlondon NetworkManager: DHCPv4: device wlan0 state changed preinit -> reboot
Feb 16 09:46:12 tlondon NetworkManager: <info>  Activation (wlan0) Stage 4 of 5 (IP4 Configure Get) scheduled...
Feb 16 09:46:12 tlondon NetworkManager: <info>  Activation (wlan0) Stage 4 of 5 (IP4 Configure Get) started...
Feb 16 09:46:12 tlondon NetworkManager:   address 10.11.14.143
Feb 16 09:46:12 tlondon NetworkManager:   prefix 24 (255.255.255.0)
Feb 16 09:46:12 tlondon NetworkManager:   gateway 10.11.14.1
Feb 16 09:46:12 tlondon NetworkManager:   nameserver '10.11.20.15'
Feb 16 09:46:12 tlondon NetworkManager:   nameserver '10.11.5.15'
Feb 16 09:46:12 tlondon NetworkManager:   nameserver '10.11.5.16'
Feb 16 09:46:12 tlondon NetworkManager:   domain name 'OBSCURED-DOMAIN'
Feb 16 09:46:12 tlondon NetworkManager: <info>  Activation (wlan0) Stage 4 of 5 (IP4 Configure Get) complete.
Feb 16 09:46:12 tlondon dhclient[9638]: bound to 10.11.14.143 -- renewal in 41552 seconds.



And here is snippet of output of 'ifconfig':

wlan0     Link encap:Ethernet  HWaddr 00:21:5D:AC:C6:92  
          inet6 addr: fe80::221:5dff:feac:c692/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:864 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:109284 (106.7 KiB)  TX bytes:4090 (3.9 KiB)



Version-Release number of selected component (if applicable):
NetworkManager-0.8.0-0.4.git20100211.fc13.x86_64

How reproducible:
Every time ......

Steps to Reproduce:
1. Try to associate with corporate/enterprise WLAN
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Tom London 2010-02-16 18:23:35 UTC
I should add that it works just fine on my "home" WLAN (uses WPA/WPA2), no PEAP, MSCHAP, etc.

Comment 2 Tom London 2010-02-16 18:26:02 UTC
For completeness, when I "disconnect" (by clicking on tray icon and selecting "disconnect"), I see this in /var/log/messages:

Feb 16 09:50:45 tlondon NetworkManager: <info>  (wlan0): device state change: 7 -> 3 (reason 39)
Feb 16 09:50:45 tlondon NetworkManager: <info>  (wlan0): deactivating device (reason: 39).
Feb 16 09:50:45 tlondon NetworkManager: (wlan0): canceled DHCP transaction, dhcp client pid 9638
Feb 16 09:50:45 tlondon kernel: mac80211-phy0: failed to remove key (0, 00:19:77:00:4f:f3) from hardware (-22)
Feb 16 09:50:46 tlondon NetworkManager: <info>  Policy set 'System eth0' (eth0) as default for routing and DNS.

Comment 3 Dan Williams 2010-02-17 19:21:33 UTC
What is the IPv6 configuration "method" from the IPv6 tab of the editor window for your network in nm-connection-editor?  Or right-click the applet icon, and choose "Edit connections...".

Comment 4 Tom London 2010-02-17 19:28:13 UTC
Edit Connections->Wireless, then Edit this network, then IPv6 settings tab:

Method says "Automatic"

Comment 5 Tom London 2010-02-17 19:31:16 UTC
Hmmm... changing method to "Ignore" allows NM to complete...

wlan0     Link encap:Ethernet  HWaddr 00:21:5D:AC:C6:92  
          inet addr:10.11.14.143  Bcast:10.11.14.255  Mask:255.255.255.0
          inet6 addr: fe80::221:5dff:feac:c692/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1727 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:198346 (193.6 KiB)  TX bytes:8540 (8.3 KiB)

Comment 6 Dan Williams 2010-02-17 19:56:18 UTC
Automatic waits for IPv6 Router Advertisements, so it'll spin until either it times out, or gets a router advertisement.  Is the network IPv6 enabled?

Comment 7 Dan Williams 2010-02-17 19:56:49 UTC
Perhaps for now we should default new connections to IPv6=Ignore

Comment 8 Tom London 2010-02-17 21:16:12 UTC
No, the WLAN is not IPv6 enabled.  Checking with IT if it can be enabled.

Works at home with my old Linksys.....

Comment 9 Tom London 2010-02-17 21:17:36 UTC
Checking the setting for my "home" WLAN, it is already set at "Ignore".

Is there something in the access point that negotiates this?

Comment 10 Dan Williams 2010-02-17 23:34:02 UTC
No, it's completely in the configuration on your machine.  But it may be that new connections (when you click on an AP from the menu) get IPv6 set to "automatic" by default, but your existing connections may have it set to Ignored already.  I forget what the default behavior is.

So, what's the bug here?  Should we make this an enhancement request to set IPv6's method to "ignored" when a new automatic connection is created (like clicking in the menu)?

Comment 11 Tom London 2010-02-17 23:52:33 UTC
Guessing that defaulting to "Ignored" will minimize the "surprise factor", certainly. 

Could certainly make this complicated by engaging in a dialog, I suppose, but that would probably cause even more confusion.

I have my IT guy finding out how/if our APs can be IPv6 enabled, but our internal corporate LAN is IPv4 only.

In any case, I'll follow your suggestion to change this to an enhancement request .....  [Sorry if I didn't do this right...]

Wondering if this could become a "common issue" that would benefit from some release notice.....

Comment 12 Dan Williams 2010-03-02 02:52:16 UTC
*** Bug 569192 has been marked as a duplicate of this bug. ***

Comment 13 James Laska 2010-03-12 14:42:38 UTC
I believe this issue may also be affecting installs (both manual and kickstart).  See bug#567978.

Comment 14 Bug Zapper 2010-03-15 15:06:04 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 15 Dan Williams 2010-06-15 16:01:57 UTC
This should be long-fixed.  New connections have IPv6 'ignored' by default, but even if they weren't, IPv6 is (by default) allowed to fail and you'll still be connected if IPv4 is successful.


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