Bug 477963 - NetworkManager sets up wrong routing for system config
NetworkManager sets up wrong routing for system config
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
10
All Linux
high Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-26 10:31 EST by Pierre Ossman
Modified: 2009-03-09 16:44 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-09 16:44:13 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)

  None (edit)
Description Pierre Ossman 2008-12-26 10:31:57 EST
When I upgraded to Fedora 10, it seems NM grew the ability to read sysconfig stuff even for non-DHCP configs. Unfortunately it somehow messed up the routing.

E.g. I have configured address 10.23.1.2, netmask 255.255.255.248. NM added the correct local and default route, except for the fact that it configured metric 1 on the local route. This is of course a bit funky as that means that there is a higher metric to the local gateway than to everything beyond it.

The kernel responded by considering everything to be locally connected. So trying to reach e.g. 1.2.3.4 resulted in "No route to host" as it couldn't find anything responding to the ARP request.

This is a production machine so I remove NM in order to get a working system, but you should be able to easily reproduce it.
Comment 1 Charles R. Anderson 2009-01-07 23:04:06 EST
Can you post your ifcfg files?  The local routes are "scope link" and in practice I am not having the issue you describe on several systems with statically configured ifcfg addressing.  I haven't specifically tried such a large netmask, though.
Comment 2 Pierre Ossman 2009-01-08 01:47:31 EST
Sure. Here's the config from one of the machines:

DEVICE=eth0
BOOTPROTO=static
BROADCAST=10.23.1.23
HWADDR=00:16:3e:ff:08:e1
IPADDR=10.23.1.18
IPV6INIT=yes
IPV6_AUTOCONF=yes
NETMASK=255.255.255.248
NETWORK=10.23.1.16
ONBOOT=yes
DNS1=10.23.0.1
NM_CONTROLLED=
Comment 3 Dan Williams 2009-02-13 06:48:25 EST
My routing table with this ifcfg:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.23.1.16      0.0.0.0         255.255.255.248 U     1      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     2      0        0 eth2
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth2

Obviously I have wifi connected right now too, and since the ifcfg above was not specified with a gateway, it won't get the default route.  Thus, all my traffic for !LAN goes out through eth2 (wifi) correctly.

NM will assign lower routing metrics to more "preferred" devices; maybe that's not quite fine-grained enough.  Ethernet > Wifi > GSM > CDMA at the moment; thus as you can see eth0 (ethernet) got a metric of 1, and eth2 (wifi) got a metric of 2.

Does your problem still happen with NetworkManager-0.7.0-2.git20090207.fc10 from f10 updates-testing?  That fixes a few odd issues with ifcfg file parsing.
Comment 4 Pierre Ossman 2009-02-26 10:39:26 EST
I was probably a bit hasty attributing this to the metric, but it was the only odd thing I could see.

The problem is still present with NetworkManager-0.7.0.97-5.git20090220.fc10.

The symptoms are the same. Everything looks peachy except for the fact that the kernel decides that everything is locally connected.

What is the kernel looking at except the routing table when it decides which IP address it needs to resolve to a MAC address to send out a packet?
Comment 5 Pierre Ossman 2009-02-26 10:48:17 EST
Ok, I've spotted the problem. NM sets the wrong gateway. I have 10.23.1.17 configured as GATEWAY in /etc/sysconfig/network, but NM sets 10.23.1.18 (the machine itself) as the gateway. This is what's screwing things up.

Could it be a miscalculation based on the very small net?
Comment 6 Dan Williams 2009-02-26 11:22:55 EST
(In reply to comment #5)
> Ok, I've spotted the problem. NM sets the wrong gateway. I have 10.23.1.17
> configured as GATEWAY in /etc/sysconfig/network, but NM sets 10.23.1.18 (the
> machine itself) as the gateway. This is what's screwing things up.
> 
> Could it be a miscalculation based on the very small net?

hmm, can you post the ifcfg file for that device?  I'll try to reproduce it.
Comment 7 Charles R. Anderson 2009-02-26 11:25:05 EST
This bug should have been fixed in 0.7.0-2.git20090207:

* Sat Feb 07 2009 Dan Williams <dcbw@redhat.com> - 1:0.7.0-2.git20090207
- ifcfg-rh: Fix issue with wrong gateway for system connections (rh #476089)

but I only tested with GATEWAY in /etc/sysconfig/network-scripts/ifcfg-ethX.  Why are you setting the gateway in /etc/sysconfig/network directly?
Comment 8 Pierre Ossman 2009-02-26 12:10:01 EST
(In reply to comment #7)
> This bug should have been fixed in 0.7.0-2.git20090207:
> 
> * Sat Feb 07 2009 Dan Williams <dcbw@redhat.com> - 1:0.7.0-2.git20090207
> - ifcfg-rh: Fix issue with wrong gateway for system connections (rh #476089)
> 
> but I only tested with GATEWAY in /etc/sysconfig/network-scripts/ifcfg-ethX. 
> Why are you setting the gateway in /etc/sysconfig/network directly?

Old habit I guess. Also, the default gateway is a global setting, even though it's tied to a specific device, so it has always made sense to have it there. The initscripts people seem to agree as GATEWAY is documented for /etc/sysconfig/network but only briefly listed for ifcfg-*.
Comment 9 Pierre Ossman 2009-02-26 12:11:07 EST
(In reply to comment #6)
> 
> hmm, can you post the ifcfg file for that device?  I'll try to reproduce it.

See earlier comment. Just add GATEWAY to /etc/sysconfig/network and you should be all set.
Comment 10 Dan Williams 2009-02-26 12:24:01 EST
Adding GATEWAY to /etc/sysconfig/network overrides *all* connection gateways; while setting GATEWAY in the ifcfg file itself would only apply to that specific connection (ie, to override DHCP-returned gateway just for that device, as opposed to overriding gateway for wlan0 *and* eth0 both).

NM will use GATEWAY from the ifcfg file first, and if its not set there, check /etc/sysconfig/network for the gateway.  If no gateway exists in the ifcfg file, but GATEWAY does exist in /etc/sysconfig/network, and NM isn't using that global gateway for all connections, then it's a bug in NM.
Comment 11 Jessica Sterling 2009-03-08 15:32:34 EDT
This bug has been triaged

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 12 Pierre Ossman 2009-03-08 15:37:48 EDT
It has been solved as well. I'm just waiting for Dan to push the update. :)
Comment 13 Dan Williams 2009-03-09 16:44:13 EDT
Should have been pushed already; please reopen if for some reason 0.7.0.99-1 doesn't help.

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