Bug 155299 - RTNETLINK: network is unreachable when running "ip route replace default ...."
RTNETLINK: network is unreachable when running "ip route replace default ...."
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: iproute (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-18 16:47 EDT by Anton Keks
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-22 02:18:57 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 Anton Keks 2005-04-18 16:47:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Firefox/1.0.2 Fedora/1.0.2-3

Description of problem:
Initial problem: default route is always absent after enabling any interface

After some digging in network scripts, I have found out that, for example, dhclient-script correctly executes the following line to add a default route:
/sbin/ip route replace default via 192.168.0.1 dev eth1

However, the command prints the following error to the console:
RTNETLINK answers: Network is unreachable

While the good old /sbin/route works flawlessly if executed manually:
/sbin/route add default gw 192.168.0.1

Moreover, running "ifup eth1" usually results in the following output:
Determining IP information for eth1...RTNETLINK answers: Network is unreachable
 done.
RTNETLINK answers: Invalid argument

I don't know the reason of the last line.

In any way, the resulting routing table is:
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.25

No default gateway there, so I have to add it manually everytime using the /sbin/route program.

Why /sbin/ip cannot add a default gateway, while /sbin/route can?

Version-Release number of selected component (if applicable):
iproute-2.6.11-1 initscripts-8.08-2 dhcp-3.0.2-7

How reproducible:
Always

Steps to Reproduce:
1. ifup eth1

Actual Results:  see above

Expected Results:  see above

Additional info:
Comment 1 Radek Vokal 2005-04-19 06:38:56 EDT
It really seems like you don't have properly configured eth1, that's why you're
getting errors from ifup script and route command. Can I have here your
/etc/sysconfig/network-scripts/ifcfg-eth1 file and also the output of ifconfig
might be useful. I've tested this on FC4t2 system will all rawhide updates and
it seems to work fine ... 
Comment 2 Valdis Kletnieks 2005-04-19 12:56:59 EDT
For what it's worth, I'm seeing it as well. (eth3 is the "main" ethernet
for this config - it's a laptop, and eth0 is the onboard, eth1 is on a
pcmcia card, and eth2 is a wireless card.  eth3 is the 100mbit on the docking
station)...

# ifdown eth3
# ifconfig eth3
eth3      Link encap:Ethernet  HWaddr 00:06:5B:EA:8E:4E  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:70789 errors:0 dropped:0 overruns:1 frame:0
          TX packets:12004 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:17411440 (16.6 MiB)  TX bytes:1234181 (1.1 MiB)
          Interrupt:11 Base address:0xec00 

# ifup eth3
RTNETLINK answers: Network is unreachable
# ifconfig eth3
eth3      Link encap:Ethernet  HWaddr 00:06:5B:EA:8E:4E  
          inet addr:128.173.14.107  Bcast:128.173.15.255  Mask:255.255.252.0
          inet6 addr: 2001:468:c80:2103:206:5bff:feea:8e4e/64 Scope:Global
          inet6 addr: fe80::206:5bff:feea:8e4e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:70970 errors:0 dropped:0 overruns:1 frame:0
          TX packets:12012 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:17426128 (16.6 MiB)  TX bytes:1234737 (1.1 MiB)
          Interrupt:11 Base address:0xec00 

# route add default gw 128.173.12.1
# cat /etc/sysconfig/network-scripts/ifcfg-eth3

## Docking station in Andrews
DEVICE=eth3
BOOTPROTO=static
BROADCAST=128.173.15.255
IPADDR=128.173.14.107
NETMASK=255.255.252.0
NETWORK=128.173.12.0
GATEWAY=128.173.12.1
GATEWAYDEV=eth3
ONBOOT=yes
HWADDR=00:06:5B:EA:8E:4E
IPV6INIT=yes
IPV6_AUTOCONF=yes

What's missing here?
Comment 3 Valdis Kletnieks 2005-04-19 13:00:23 EDT
My kernel is 2.6.12-rc2-mm3, but looking at the -mm3 patch and the patches that
are in the -1240 kernel, I don't see anything divergent that should cause a
problem...
Comment 4 Anton Keks 2005-04-19 16:18:46 EDT
My kernel is 2.6.11 from FC4, recompiled with some unneeded drivers disabled.
The machine is a laptop and the problem is reproducable for any network
interface (both 1000 Mbit ethernet and integrated Wifi)

With the "clean" Fedora Core 3 and the exact same network configuration it
worked perfectly. Now, as I have already said, /sbin/route works perfectly, but
/sbin/ip fails.

Here is my interface configuration (generated by system-config-network):
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
IPV6INIT=no
ONBOOT=no
USERCTL=yes
PEERDNS=yes
GATEWAY=192.168.0.1
TYPE=Wireless
DEVICE=eth1
BOOTPROTO=dhcp
NETMASK=255.255.255.0
DHCP_HOSTNAME=
IPADDR=192.168.0.34
HWADDR=00:0e:35:8d:d6:b7
DOMAIN=
ESSID=ziba
CHANNEL=1
MODE=Managed
RATE=Auto

Output of ifconfig eth1:
eth1      Link encap:Ethernet  HWaddr 00:0E:35:8D:D6:B7  
          inet addr:192.168.0.25  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1695 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1429 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1991409 (1.8 MiB)  TX bytes:383087 (374.1 KiB)
          Interrupt:11 Base address:0x2000 Memory:d0214000-d0214fff 

As you can see, everything looks normal, and it seems that the problem doesn't
depend on the interface configuration at all. It is even reproducible for
ethernet interface eth0 with static IP.
Comment 5 Henrik Nilsson 2005-08-09 05:20:52 EDT
I have what seems to be the same or at least a very similar problem with
Fedora Core 4.

Maybe this report should be filed as a FC4 bug instead of a FC4test2
bug followup?

Anyway, I have a laptop (Dell D600) with a single (wired) ethernet interface.
About as standard as it can be. I have a fresh FC4 installation, fully updated
on 8 August 2005 using Yum, and I'm running a stock kernel.

When I chose the network to be configured dynamically using DHCP, I do not
get any default route in the routing tables (according to /sbin/route),
and consequently I can only reach machines on the local (sub)net.

I have observed this behaviour in two totally different environments
(a university in the UK and one in Sweden). I recently upgraded from FC2,
and I didn't have any trouble on either site with FC2.

Interestingly, if I, using the standard FC4 network configuration tool,
first switch to manual network configuration, then manually enter the
IP address for the proper gateway, then switch back to automatic
configuration via DHCP, then save the changes and bring up the ethernet
interface, then I do get a default route.

That is, as far as I can tell, the MANUAL gateway setting takes effect
DESPITE chosing configuration via DHCP. That might explain why "ip route"
complains about "network unreachable" and no default route gets added
to the routing table, although I have not personally seen the error
message described above.

I have the following components that, according to the original bug report,
are the most relevant to this problem:

    iproute-2.6.11-1
    initscripts-8.11.1-1
    dhclient-3.0.2-14.FC4

For refernce, here are my current network settings:

seshat-17% ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0F:1F:B8:41:4A
          inet addr:129.16.247.15  Bcast:255.255.255.255  Mask:255.255.255.192
          inet6 addr: fe80::20f:1fff:feb8:414a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10969 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10349 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4107017 (3.9 MiB)  TX bytes:1061206 (1.0 MiB)
          Interrupt:11

seshat-18% cat /etc/sysconfig/networking/devices/ifcfg-eth0
# Broadcom Corporation|NetXtreme BCM5705M Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0F:1F:B8:41:4A
ONBOOT=yes
TYPE=Ethernet
DHCP_HOSTNAME=seshat
USERCTL=yes
PEERDNS=yes
IPV6INIT=no
IPADDR=129.16.247.15
NETMASK=255.255.255.192
GATEWAY=129.16.247.1

I repeat that I manually have to set GATEWAY to whatever is right for the
environment I'm in, despite BOOTPROTO being DHCP.

Here are the resulting routing tables:
seshat-19% route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
129.16.247.0    *               255.255.255.192 U     0      0        0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
default         cth247a-gw.chal 0.0.0.0         UG    0      0        0 eth0

If I change GATEWAY to something different, like 192.168.0.1, the routing
table becomes

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
129.16.247.0    *               255.255.255.192 U     0      0        0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0

and I cannot reach any networks beside the local one.


Comment 6 Radek Vokal 2005-08-10 04:01:35 EDT
(In reply to comment #5)
This comment seems to me more like s-c-network bug. It should remove old GATEWAY
and NETMASK lines from the initscript or suppress the settings (just found bug
#162553 which describes the above problem). Still persists the problem with no
default gateway with first network start and I'm still not on trace to this .. :(  
Comment 7 Christopher Brown 2005-08-19 15:05:37 EDT
I am also seeing this against 20050819 rawhide. Any further information (error
and workaround are identical) please ask.
Cheers
Chris
Comment 8 Christopher Brown 2005-08-20 09:57:36 EDT
Now fixed in 20050820.
Comment 9 Radek Vokal 2005-08-22 02:18:57 EDT
(In reply to comment #8)
> Now fixed in 20050820.

Thanks for testing, I'm closing this bug. 

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