Bug 437338

Hmm; can't reproduce with SVN trunk; will try on a rawhide machine.  Can you
stop NM, then run /usr/sbin/NetworkManager --no-daemon, get it into this state,
and attach the output?

Created attachment 297958 [details]
NM output

So one of the devices can't DHCP and falls back to autoip; that's expected for
the version of NM you're running; though I've changed that and new versions of
NM will just fail the connection if DHCP fails.

I think the bug here is that even though there is an active non-IPv4-LL device,
it picks the IPv4LL device to be the default.  I'll fix that.

*** Bug 438199 has been marked as a duplicate of this bug. ***

Looks better; thanks.

I'm somewhat confused by the nm-applet behaviour though.

Now it seems to have two devices, both identically named "Wired Networks (PASemi
Unknown (0xa005))". And under each one I seem to have a _choice_ of which
network to join, each one offering me the choice of "System eth1" or "System eth0".

Shouldn't there be a _single_ option available for each physical device (at
least until/unless you start supporting VLAN), and shouldn't each device be
identifiable?

Have you MAC-locked the ifcfg files to their specific adapters?  If you have, NM
will (shortly, not quite yet) only show you the connections which apply to
specific devices.

This is a completely fresh install (apart from fetching the newer NM and rebooting).

I think the installer bits that write out the ifcfg-eth0 and ifcfg-eth1 do stuff
the MAC into those files, so thats still probably what th issue is here.  It
should get magically fixed in a release quite soon.

I have two NICs which were auto-configured by anaconda fresh install today from
rawhide 2008-04-07.  Here are the /etc/sysconfig/network-scripts/ifcfg-eth* files:

# Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:13:72:74:da:15
ONBOOT=yes
DHCP_HOSTNAME=dustpuppy.wpi.edu

# Lite-On Communications Inc LNE100TX
DEVICE=eth1
BOOTPROTO=dhcp
HWADDR=00:a0:cc:da:ed:04
ONBOOT=no
DHCP_HOSTNAME=dustpuppy.wpi.edu

In nm-applet, I see two sections for "Wired Networks" and under each there is a
"System eth0" and a "System eth1".  I'm having a problem with the default route
disappearing after awhile or not being set at all after bootup and login.

Do the latest rawhide updates fix this for you?  Anything over svn3527 should
ensure that the MAC-locking of the ifcfg is respected, both in NM and the applet.

The behavior I'm seeing with latest rawhide is that both devices are brought up,
but the eth1 one, for which it receives NO default route via DHCP, is getting
selected as the "active" device to use for the default route.  As a result, this
is my routing table which is less than useful:

#netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
130.215.201.0   0.0.0.0         255.255.255.0   U         0 0          0 eth0
172.27.0.0      0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 eth1

It should instead be:

#netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
130.215.201.0   0.0.0.0         255.255.255.0   U         0 0          0 eth0
172.27.0.0      0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         130.215.201.1   0.0.0.0         UG        0 0          0 eth0

Created attachment 303233 [details]
[PATCH] don't use route and DNS for device that has no default gateway configuration

Here is a patch that ignores devices without a default gateway when selecting
the best device to use for the default gateway and DNS information.  I tested
this and it seems to work nicely for my dual NIC scenario, one DHCP w/default
route, the other with no default route.

Thanks for the patch, variation committed upstream, in svn r3586.

Been pushed out in recent builds; definitely in latest koji 3614

NetworkManager-0.7.0-0.6.8.svn3669.fc8 has been submitted as an update for Fedora 8

Created attachment 309585 [details]
Files relevant to the descibed network bug

I encountered this bug (again) on the release of F9.

I installed F9 from zero on a x86_64 machine with only one network adapter with
both static IPv4 and static IPv6 addresses. If I boot into the system I do not
have a default gateway. After doing "/etc/rc.d/init.d/network restart" I do see
a default gateway. This is reproduceable on every reboot.

nm-tools showes me "default gateway 0.0.0.0".

/etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth0 seem to be
normal and a default gateway should be expected.

Following comment #17 I think this bug should be reopened.

NetworkManager-0.7.0-0.6.9.svn3675.fc8, NetworkManager-openvpn-0.7.0-10.svn3632.fc8, NetworkManager-vpnc-0.7.0-0.7.7.svn3627.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.