After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 341439 - Routing of my wired network not set up properly
Routing of my wired network not set up properly
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
0.6.6
Other All
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2006-05-11 16:58 UTC by Jacek Chrzaszcz
Modified: 2008-11-10 04:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fragment of /var/log/messages (5.42 KB, text/plain)
2006-05-11 17:04 UTC, Jacek Chrzaszcz
Details
Output of ifup-eth (2.31 KB, text/plain)
2006-05-31 12:32 UTC, Jacek Chrzaszcz
Details

Description Jacek Chrzaszcz 2006-05-11 16:58:47 UTC
Please describe the problem:
I am using FC5. After plugging in the RJ11 plug of my faculty network,
NetworkManager says "wired connection established", but the routing table is not
properly set and the gateway is not visible. 

Setting up the network via dhcp without NM works.

With my home network NM works well.

Steps to reproduce:
1. start NetworkManager
2. connect to my faculty wired network (sorry folks ;)
3. ping 66.249.93.99


Actual results:
connect: Network is unreachable


Expected results:
PING 66.249.93.99 (66.249.93.99) 56(84) bytes of data.
64 bytes from 66.249.93.99: icmp_seq=1 ttl=246 time=220 ms
64 bytes from 66.249.93.99: icmp_seq=2 ttl=246 time=221 ms

--- 66.249.93.99 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 220.328/221.095/221.863/0.900 ms


Does this happen every time?
yes, I tested NM 0.6.0 from FC5 updates and NM 0.6.2 from updates-testing

Other information:
This is the routing table obtained from "ifup eth0" without NetworkManager:
[root@minio fonts]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.2.31       0.0.0.0         255.255.255.255 UH    0      0        0 eth0
10.1.6.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         10.1.2.31       0.0.0.0         UG    0      0        0 eth0

This is the routing table with NM:
[root@minio fonts]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.6.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0

This is the information on the network found in /var/log/messages:
May 11 18:53:18 minio NetworkManager: <information>     Retrieved the following
IP4 configuration from the DHCP daemon:
May 11 18:53:18 minio NetworkManager: <information>       address 10.1.6.26
May 11 18:53:18 minio NetworkManager: <information>       netmask 255.255.255.0
May 11 18:53:18 minio NetworkManager: <information>       broadcast 10.1.2.255
May 11 18:53:18 minio NetworkManager: <information>       gateway 10.1.2.31
May 11 18:53:18 minio NetworkManager: <information>       nameserver 10.1.3.1
May 11 18:53:18 minio NetworkManager: <information>       nameserver 10.1.2.9
May 11 18:53:18 minio NetworkManager: <information>       domain name 'mimuw.edu.pl'
Comment 1 Jacek Chrzaszcz 2006-05-11 17:04:28 UTC
Created attachment 65260 [details]
Fragment of /var/log/messages

This is the fragment of /var/log/messages from the insertion of the eth plug (sorry it's RJ45 not RJ11, isn't it? ;)
Comment 2 Mike Paul 2006-05-18 23:44:15 UTC
With a netmask of 255.255.255.0, your IP address (10.1.6.26) and your gateway (10.1.2.31) are not actually on the same subnet.  As far as IP is concerned, 10.1.2.31 is on a different network from your computer and therefore is not reachable.  It appears that your DHCP server may be giving out bad leases.

The first entry in your "good" routing table is a host entry which says the gateway is directly reachable through eth0.  That shouldn't be necessary -- normally the route for the local subnet (the second entry in your "good" routing table, and the only entry in the bad one) matches the gateway as well.

It's worth looking into what's generating that host route in the non-NetworkManaged case.  It might be some distribution-specific script hooked into the DHCP client, or it might be a route provided as part of the DHCP lease itself.  (If the latter, it would mean the DHCP server isn't actually giving out bad leases, but instead that NM is ignoring information provided in the lease.)  Either way it would be helpful in determining the nature of the problem.
Comment 3 Jacek Chrzaszcz 2006-05-31 12:30:48 UTC
I'm sorry it took me so long :)

I am not a network expert, but I must agree that the network config is somewhat strange... but it works with the default connection mechanism, so guess what the admin would tell me if asked to change this ;)

I narrowed down the precise place where this route is added in the Fedora script.
It is /sbin/dhclient which does this.

It is invoked in the script /etc/sysconfig/network-scripts/ifup-eth

I put some debug stuff in
the script and the following fragment of the script:

    echo DEBUG 850
    route -n
    for i in ${DHCLIENTARGS} ${DEVICE}; do if [ -f "$i" ]; then echo File $i; cat $i; else echo Option $i; fi; done
    set -x

    if /sbin/dhclient ${DHCLIENTARGS} ${DEVICE} ; then
        echo $" done."
    else
        echo $" failed."
        exit 1
    fi
  else
    ....
fi

echo DEBUG 900
route -n
  

prints out the content of the attachment ("Zrobione" means done in Polish :)

Jacek
PS. The script comes from this FC5 package: initscripts-8.31.1-1
/sbin/dhclient comes from dhclient-3.0.3-26
Comment 4 Jacek Chrzaszcz 2006-05-31 12:32:40 UTC
Created attachment 66526 [details]
Output of ifup-eth
Comment 5 Dan Williams 2008-11-05 15:54:22 UTC
Is this still a problem with 0.6 or 0.7?
Comment 6 Jacek Chrzaszcz 2008-11-07 16:20:13 UTC
I can't tell as the network layout at my faculty has changed (several times) since the bug was reported. Now the layout is standard, i.e., the gateway is on the local network. 

BTW: NetworkManager-0.7.0-0.11.svn4022.4.fc9.i386 works well for me now!
Comment 7 Dan Williams 2008-11-10 04:07:58 UTC
ok, thanks.