Bug 587513 - Unable to reconnect to a dual-stacked network
Unable to reconnect to a dual-stacked network
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 538499
  Show dependency treegraph
 
Reported: 2010-04-30 02:19 EDT by Tore Anderson
Modified: 2010-05-02 17:35 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-02 17:35:34 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)
/var/log/messages (82.86 KB, text/plain)
2010-04-30 02:19 EDT, Tore Anderson
no flags Details

  None (edit)
Description Tore Anderson 2010-04-30 02:19:58 EDT
Created attachment 410312 [details]
/var/log/messages

Description of problem:

When NM is started in a network environment with IPv4 DHCP and IPv6 RA/SLAAC (with RDNSS), it will connect after boot just fine the first time, and both the IPv6 and the IPv4 name servers wil make it into /etc/resolv.conf.

However, if I attempt to re-connect to the network from the GNOME applet drop-down menu, it doesn't ever finish.  The applet sits there with two dots green and a spinning blue thing.

Version-Release number of selected component (if applicable):

NetworkManager-0.8.0-9.git20100429.fc12.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Boot up
2. Select "System eth0" in nm-applet drop-down menu to trigger a reconnection
  
Actual results:

Reconnection process never finishes.  Network unuseable.

Expected results:

Reconnection finished quickly.


Additional info:

See attached log.  The first reconnection I attempted at 07:55:40, by selecting "System eth0" in the drop-down menu while I was still connected.  At 08:02:10 I gave up waiting and deselected first "disable networking" and then selecting it again at 08:02:14.  Same results.  At 08:04:36 I disabled networking again, saved the log, and rebooted (which successfully reconnected me to the network)
Comment 1 Scott Schmit 2010-04-30 07:28:12 EDT
I'll reboot in a little bit just in case it matters, but I can't reproduce Tore's success: I've done:
# /etc/init.d/NetworkManager stop
# rmmod iwlagn
# > /etc/resolv.conf # I'll file a bug for this
## at this point, as far I as I know, I should have reset any state that would affect NetworkManager as far as first time vs Nth time, but I could be wrong
# modprobe iwlagn
# /etc/init.d/NetworkManager start
## sits at the two dots, spinning, with SLAAC IPv6, no IPv4, and empty /etc/resolv.conf (no RDNSS info)
Comment 2 Tore Anderson 2010-04-30 07:40:17 EDT
Scott,

I've seen NM being dependent on what is done by the kernel prior to what NM is doing before (see bug #530670 for example).  Since I'm testing with wired ethernet, SLAAC will likely have been performed by the kernel even before NM has started, while in your case with a WLAN, probably not (since NM needs to program the SSID, possibly start the wpa_supplicant, and so on).

I thought that might be the case here, too.  Perhaps you can test using wired Ethernet, too?

Tore
Comment 3 Scott Schmit 2010-04-30 07:58:19 EDT
I rebooted, and it changed nothing. But I'm using wifi while Tore's using Ethernet.

So I went over and plugged in the Ethernet cable, and it duplicates Tore's initial success. I then unplugged the Ethernet cable and reconnected it. It sits at two dots and swirls. However, there is a difference: eth0 only has the link local address, whereas in the wireless case (connect or reconnect), I would always have all the SLAAC addresses from RA.

If I follow the recipe I showed above...it reverts back to the "initial connect" behavior. I don't really even need to rmmod/modprobe either. A simple NetworkManager restart works fine.

So this happens to be the wireless analog to the wifi case I've been noticing for a while, but haven't gotten around to filing because I don't know how to reproduce it--sometimes the (wifi) network will stall out and stop being responsive (low signal strength? not sure). This is clearly a driver problem, I would think, and that seems confirmed in that if I disconnect and reconnect, it doesn't work (sits and spins). But what contradicts that theory is that if I restart NetworkManager (but leave the driver alone), it connects without a hitch.

Could these behaviors be related? Honestly, there is no reason for NetworkManager to behave differently for initial connect vs. reconnect. It seems like something isn't getting reset properly during a reconnect.
Comment 4 Scott Schmit 2010-05-02 15:11:12 EDT
As best I can tell, this bug is fixed. I've tried wired & wireless via auto DHCP/auto. I've also tried wireless auto DHCP/ignore & disabled/auto and they connect correctly as well. (IPv6 only I am able to ping6 ipv6.google.com so the routes are right too).

I've disconnected, reconnected, etc.
Comment 5 Tore Anderson 2010-05-02 17:35:34 EDT
This bug appears to be fixed in NM git20100502, closing.

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