Bug 464417 - NetworkManager-0.7.0-0.11.svn4022.fc9.i386 chokes on static, wired network
Summary: NetworkManager-0.7.0-0.11.svn4022.fc9.i386 chokes on static, wired network
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 9
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-09-28 14:19 UTC by Chris Rankin
Modified: 2008-10-03 22:35 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-03 22:33:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Extract from /var/log/messages, for starting up NM (4.66 KB, text/plain)
2008-09-28 14:19 UTC, Chris Rankin
no flags Details
Static connection on Fedora 9 (2.18 KB, text/plain)
2008-09-30 09:09 UTC, Chris Rankin
no flags Details
gconftool output for static connection on F9, before starting NM (2.18 KB, text/plain)
2008-09-30 09:34 UTC, Chris Rankin
no flags Details
gconftool output for static connection on F9, after starting NM (2.18 KB, text/plain)
2008-09-30 09:36 UTC, Chris Rankin
no flags Details
eth0 configuration script (318 bytes, text/plain)
2008-09-30 12:14 UTC, Chris Rankin
no flags Details
Incorrect information from Connection Information screen (33.44 KB, image/png)
2008-10-01 11:02 UTC, Chris Rankin
no flags Details
Incorrect information from F8 Connection Information screen (32.81 KB, image/png)
2008-10-01 12:33 UTC, Chris Rankin
no flags Details

Description Chris Rankin 2008-09-28 14:19:10 UTC
Created attachment 317901 [details]
Extract from /var/log/messages, for starting up NM

Description of problem:
This problem has only started happening since the updates I downloaded last night. Basically, I turned the PC on this morning and the network was broken. Stopping NetworkManager fixed the problem.

Version-Release number of selected component (if applicable):
0.7.0-0.11.svn4022

How reproducible:
All the time.

Steps to Reproduce:
1. /etc/rc.d/init/NetworkManager start
2.
3.
  
Actual results:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.0.0.0       *               192.0.0.0       U     0      0        0 eth0

Notice the lack of a default route. And even if I add a default route manually, I still get nonsense like this:

# traceroute www.phoronix.com
traceroute to www.phoronix.com (209.62.40.52), 30 hops max, 40 byte packets
 1  volcano.underworld (192.168.0.3)  3000.970 ms !H  3000.970 ms !H  3000.966 ms !H

The ifconfig results are ridiculous too. Look at the netmask and broadcast address:
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0D:56:0D:E7:3F  
          inet addr:192.168.0.3  Bcast:255.255.255.255  Mask:192.0.0.0
          inet6 addr: fe80::20d:56ff:fe0d:e73f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14570 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14045 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:11395384 (10.8 MiB)  TX bytes:2506721 (2.3 MiB)

Expected results:
This is what my ifcfg-eth0 script gives me instead, once I KILL NetworkManager:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     0      0        0 eth0
224.0.0.0       *               240.0.0.0       U     0      0        0 eth0
default         wellhouse.under 0.0.0.0         UG    0      0        0 eth0

# traceroute www.phoronix.com
traceroute to www.phoronix.com (209.62.40.52), 30 hops max, 40 byte packets
 1  wellhouse.underworld (192.168.0.1)  0.576 ms  0.792 ms  1.019 ms
...
20  et1-3.ibr02.hstntx2.theplanet.com (70.87.253.58)  132.559 ms  135.777 ms  136.508 ms
21  po2.car02.hstntx2.theplanet.com (74.55.252.102)  137.234 ms  111.863 ms  113.765 ms
22  ev1s-209-62-40-52.theplanet.com (209.62.40.52)  111.999 ms  113.102 ms  113.463 ms

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0D:56:0D:E7:3F  
          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20d:56ff:fe0d:e73f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14764 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14258 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:11424900 (10.8 MiB)  TX bytes:2537544 (2.4 MiB)


Additional info:
I have a small local network, and this particular is just a node. It is not the machine connected to my ADSL modem.

I cannot use the gnome Network Manager applet to add sensible values for my wired, static network. This applet INSISTS that my network mask be "2".

Comment 1 Chris Rankin 2008-09-28 14:23:05 UTC
These are the packages that I "upgraded" to last night:

Sep 27 22:51:01 Updated: xulrunner-1.9.0.2-1.fc9.i386
Sep 27 22:51:14 Installed: xine-lib-1.1.15-1.fc9.i386
Sep 27 22:51:36 Updated: devhelp-0.19.1-4.fc9.i386
Sep 27 22:51:47 Updated: yelp-2.22.1-5.fc9.i386
Sep 27 22:51:48 Updated: gnome-python2-extras-2.19.1-18.fc9.i386
Sep 27 22:51:58 Updated: firefox-3.0.2-1.fc9.i386
Sep 27 22:52:03 Updated: seamonkey-1.1.12-1.fc9.i386
Sep 27 22:52:04 Updated: gnome-python2-libegg-2.19.1-18.fc9.i386
Sep 27 22:52:04 Updated: gnome-python2-gtkhtml2-2.19.1-18.fc9.i386
Sep 27 22:52:04 Updated: totem-xine-2.23.2-7.fc9.i386
Sep 27 22:52:27 Updated: totem-2.23.2-7.fc9.i386
Sep 27 22:52:28 Updated: totem-gstreamer-2.23.2-7.fc9.i386
Sep 27 23:04:22 Updated: docbook-dtds-1.0-38.fc9.noarch
Sep 27 23:04:23 Updated: postgresql-libs-8.3.4-1.fc9.i386
Sep 27 23:04:35 Updated: foomatic-3.0.2-67.fc9.i386
Sep 27 23:04:35 Installed: dnsmasq-2.41-0.8.fc9.i386
Sep 27 23:04:35 Installed: avahi-autoipd-0.6.22-10.fc9.i386
Sep 27 23:04:38 Updated: postgresql-8.3.4-1.fc9.i386
Sep 27 23:04:38 Updated: 1:NetworkManager-glib-0.7.0-0.11.svn4022.fc9.i386
Sep 27 23:04:39 Updated: 1:NetworkManager-0.7.0-0.11.svn4022.fc9.i386
Sep 27 23:04:41 Updated: 1:NetworkManager-gnome-0.7.0-0.11.svn4022.fc9.i386

Comment 2 Chris Rankin 2008-09-28 20:16:34 UTC
Someone has decided that this version of NetworkManager be inflicted on F8 users too, so now my laptop's wired network is also broken. Except this time, NetworkManager is forcing the wired interface's netmask to be "7". Don't ask me why: I've tried everything short of Dark Magic to reset it to "24" in the Connection Editor dialog. But something keeps quietly setting it back to "7".

Comment 3 Michal Jaegermann 2008-09-29 19:24:10 UTC
AFAICS this version of NM does not work with wired DHCP
connections either.  No connections of any sort are
recognized, period, so I do not have anything to edit
(similar to something from comment #2).

I also got that while running upgrade on F8:

  Cleanup        : NetworkManager-gnome                            [19/24]
error reading information on service NetworkManagerDispatcher: No such file or directory
error reading information on service NetworkManagerDispatcher: No such file or directory
error reading information on service NetworkManagerDispatcher: No such file or directory

but I guess this is coincidental and an ordering in
yum handling.  Right?

Does dnsmasq service, which instalation was forced by an NM
update, is supposed to be running?  chkconfig shows it "off"
on all levels.

Comment 4 Dan Williams 2008-09-30 01:09:48 UTC
The errors about NetworkManager dispatcher are harmless; the dispatcher has been replaced by a callout that is started on demand and then quits, saving memory when it's not in use.

dnsmasq is used for connection sharing and is also started on demand by NM so that it's not running when it's not required.

I'm looking into the static IP issues with my F8 machine.

Comment 5 Dan Williams 2008-09-30 02:10:14 UTC
I can't quite get NM to behave this way with a static connection... I installed 3675, cleared all connections, and set up a static IP connection.  A bug in 3675 required that I enter the netmask as "24.0.0.0" (NM uses prefixes but the connection editor in 3675 wasn't correctly accepting them), which I then saved, and connected.  I verified that the address and netmask were correct using ifconfig.  I then upated to 4022, rebooted, NM reconnected, and I verified that the netmask was still correct using ifconfig.

Be careful when you enter the prefix/netmask into the connection editor, you have to hit return or click in another field before hitting the OK button or the change won't take.  That's a focus bug that's been there since 3675 anyway.

Can people trawl through GConf and tell me what's there for their netmask/prefix?  The output of:

gconftool-2 --dump /system/networking/connections/1

where "1" is the ID of the connection should dump it out, it'll be the second item in each IP address triplet.  It should be in the range of 0 - 32 since it's a prefix, though the applet should accept either prefixes or netmasks and convert internally to a prefix.

Comment 6 Chris Rankin 2008-09-30 09:09:48 UTC
Created attachment 318050 [details]
Static connection on Fedora 9

And the netmask is "2", which is silly. It should be "24".

Comment 7 Chris Rankin 2008-09-30 09:19:27 UTC
So I tried it again (on F9), this time with the buggy "24.0.0.0" format for the netmask. And I pressed enter. And it seemed to take in the connection editor, although the interface wasn't reconfigured to match. And so I restarted NM, and the netmask became 2 again.

I hadn't previously tried "24.0.0.0" as a netmask format, on either F8 or F9, for the obvious reason that it's pants.

Comment 8 Chris Rankin 2008-09-30 09:34:16 UTC
Created attachment 318051 [details]
gconftool output for static connection on F9, before starting NM

So I've been bashing on the connection editor again, and I've been forcing the correct values in, and then manually reconfiguring the interface to match what NM should have done. And then I stopped NM, and dumped the output.

Comment 9 Chris Rankin 2008-09-30 09:36:13 UTC
Created attachment 318052 [details]
gconftool output for static connection on F9, after starting NM

And once the gconftool output looked OK, I restarted NM and saw this.

Comment 10 Dan Williams 2008-09-30 11:47:24 UTC
yeah, 24.0.0.0 is complete bunk; it was a bug in the prefix/netmask parsing code on 3675.  That was just what I found the old version to do.

Chris, is your connection a user connection or a system connection?  Do you have any /etc/sysconfig/network-scripts/ifcfg-* files and if so, do they have NETMASK or PREFIX items?

Trying to set the netmask on 4088 in the connection editor, either as "255.255.255.0" or "24", shows up correctly the next time the connection editor is launched.  Is that not the case for you?

Also, this is i386 not PPC, right?

Comment 11 Chris Rankin 2008-09-30 12:14:26 UTC
Created attachment 318065 [details]
eth0 configuration script

Here is my ifcfg-eth0 script. I probably initially configured this "by hand" years ago (early FC?), and then refined it using the system tools. There's nothing suspicious about eth0 in the "Network Tools" GUI.

Yes, this is an i386 machine (actually a dual P4 Xeon, with HT enabled, running an SMP kernel.)

> Trying to set the netmask on 4088 in the connection editor, either as
> "255.255.255.0" or "24", shows up correctly the next time the connection
> editor is launched.

Actually, yes, that's fine. My point with the two outputs from gconftool-2 was that these values don't survive the following:

/etc/rc.d/init.d/NetworkManager stop
    <created attachment 318051 [details] here>
/etc/rc.d/init.d/NetworkManager start
    <created attachment 318052 [details] here>

Comment 12 Dan Williams 2008-09-30 17:33:40 UTC
Can you provide the output of:

rpm -q --queryformat "%{name}-%{version}-%{release}.%{arch}\n" NetworkManager

for me?  I tried to reproduce but can't seem to do so using both your ifcfg and the GConf connection.  Need to verify what exact versions of NM you have.  Is your machine x86-64 or i386?

Comment 13 Chris Rankin 2008-09-30 17:38:19 UTC
(In reply to comment #12)
> Can you provide the output of:
> 
> rpm -q --queryformat "%{name}-%{version}-%{release}.%{arch}\n" NetworkManager
> 
> for me?

Ta-da! (And it's i386, not x86-64.)

$ rpm -q --queryformat "%{name}-%{version}-%{release}.%{arch}\n" NetworkManager
NetworkManager-0.7.0-0.11.svn4022.fc9.i386

Comment 14 Dan Williams 2008-09-30 19:33:21 UTC
Chris; in the connection editor you're editing the "Auto Ethernet" connection, right?  Do you see any other wired connections there other than "Auto Ethernet"?

Comment 15 Chris Rankin 2008-09-30 20:03:39 UTC
(In reply to comment #14)
> Chris; in the connection editor you're editing the "Auto Ethernet" connection,
> right?

Correct.

> Do you see any other wired connections there other than "Auto Ethernet"?

No, "Auto Ethernet" is all alone.

Comment 16 Chris Rankin 2008-10-01 11:02:27 UTC
Created attachment 318181 [details]
Incorrect information from Connection Information screen

I have just noticed that although the "Editing Auto Ethernet" dialogue box is currently showing the correct information, the "Connection Information" window is most certainly NOT! And this is despite my reconfiguring eth0 manually beforehand. So where is the "Connection Information" window reading its information from? 

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0D:56:0D:E7:3F  
          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20d:56ff:fe0d:e73f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:49288 errors:0 dropped:0 overruns:0 frame:0
          TX packets:37437 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:59016744 (56.2 MiB)  TX bytes:5120343 (4.8 MiB)

One other thing I've noticed: In the "Edit Connections" window, it's not just the Network Mask that keeps getting zapped from "24" to "2". The Gateway address is also being zapped from "192.168.0.1" to "0.0.0.0".

Comment 17 Chris Rankin 2008-10-01 12:33:00 UTC
Created attachment 318186 [details]
Incorrect information from F8 Connection Information screen

Here is the same connection information for my laptop, which is running Fedora 8.

Cross-checking the connection information with a box that happens to work (F9, RealTek ethernet, never ran NM before today), shouldn't there also be a line here saying "Default Route"?

I've also noticed that the "Edit Connections" dialogue modifies the "Auto Ethernet" connection every 5 minutes, so that it cycles from "now" to "1 minute ago" up to "4 minutes ago" before going back to "now". And at the start of a new cycle, the netmask and gateway address have (sometimes) been silently zapped back to "7" and "0.0.0.0" again respectively. So when I previously said that I could reopen "Edit Connections" and see the correct "Auto Ethernet" information, I hadn't realised that the time interval between resetting it and rechecking it was significant.

And here's the package information too:

$ rpm -q --queryformat "%{name}-%{version}-%{release}.%{arch}\n" NetworkManager
NetworkManager-0.7.0-0.11.svn4022.fc8.i386

Comment 18 Dan Williams 2008-10-01 13:51:00 UTC
Chris: thanks; that's very useful information.  I'll leave my F8 machine alone for a bit and track that down.  Quite helpful.

Comment 19 Dan Williams 2008-10-01 15:28:14 UTC
Hmm, how long did you have to wait until this occurred?  I've let it go for about 20 minutes so far with no corruption to my static wired connection.  Maybe it just takes longer?  What were you doing in the interim?

Comment 20 Chris Rankin 2008-10-01 15:51:26 UTC
(In reply to comment #19)
> Hmm, how long did you have to wait until this occurred?  I've let it go for
> about 20 minutes so far with no corruption to my static wired connection. 
> Maybe it just takes longer?  What were you doing in the interim?

I wasn't doing anything other than surf, etc. Some background process is updating my "Auto Ethernet" connection every 5 minutes, and the only way that I can get a timestamp older than "4 minutes ago" is to keep the "Edit Connection" dialogue open and then clobber the update by closing it.

Comment 21 Dan Williams 2008-10-01 16:10:00 UTC
the applet updates the timestamp on the connection every 5 minutes so that it knows what connections you've used

Comment 22 Chris Rankin 2008-10-01 16:22:07 UTC
(In reply to comment #21)
> the applet updates the timestamp on the connection every 5 minutes so that it
> knows what connections you've used

I suspect that your static connection isn't broken though. Mine starts broken and is rebroken every 5 minutes, despite my efforts to fix it. By the sound of it, yours starts fixed and stays fixed. Where does the "Connection Information" window get its data from? It can't be from either the interface itself or the repository that gconftool-2 reads, because I always fix both of those.

Comment 23 Dan Williams 2008-10-01 17:00:47 UTC
Connection Information gets the info directly from NetworkManager's current interface state, which should be the same as you see with /sbin/ifconfig.

Comment 24 Dan Williams 2008-10-01 17:11:12 UTC
confirmed, can reproduce the issue where the applet does not respect changes made in the connection editor to the active connection.  Fixing...

Comment 25 Chris Rankin 2008-10-01 17:47:56 UTC
(In reply to comment #23)
> Connection Information gets the info directly from NetworkManager's current
> interface state, which should be the same as you see with /sbin/ifconfig.

This can't possibly be true. See comment #16, where I explicitly tested this. The output from ifconfig is completely different to the applet's Connection Information window.

Comment 26 Chris Rankin 2008-10-01 18:10:12 UTC
(In reply to comment #24)
> confirmed, can reproduce the issue where the applet does not respect changes
> made in the connection editor to the active connection.  Fixing...

OK, thanks. But I still don't understand where my bad initial configuration values come from. I have tried doing the following:

a) Start NetworkManager
b) Fix the connection information with the applet's "Edit Connection" dialogue.
c) Stop the NetworkManager before the 5 minute timeout expires. This leaves correct information in the gconftool-2 database.
d) Run "ifup eth0" to configure eth0 correctly the old-fashioned way, so that the ifconfig information is also correct.
e) Start NetworkManager again.

When NM tells me that I have been connected to the wired network, I discover that the broken values are back.

Comment 27 Dan Williams 2008-10-01 21:40:09 UTC
the overwriting issue is fixed upstream in NM svn r4134, will backport

I still wonder why the initial prefix/netmask got corrupted after the install, but I bet nobody has a pristine pre-update system still that they can get a GConf dump out of...

Comment 28 Fedora Update System 2008-10-01 22:14:27 UTC
NetworkManager-0.7.0-0.11.svn4022.4.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0-0.11.svn4022.4.fc9

Comment 29 Fedora Update System 2008-10-01 22:14:29 UTC
NetworkManager-0.7.0-0.11.svn4022.4.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/NetworkManager-0.7.0-0.11.svn4022.4.fc8

Comment 30 Fedora Update System 2008-10-03 22:33:51 UTC
NetworkManager-0.7.0-0.11.svn4022.4.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 31 Fedora Update System 2008-10-03 22:35:51 UTC
NetworkManager-0.7.0-0.11.svn4022.4.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.


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