network manager 0.7 multiple wired interfaces and default route used not selectable

[Jason Kraft]

Binary package hint: network-manager

I installed network-manager from PPA using Hardy. I have 2 network interfaces. After both interfaces are up I run netstat -rn and see:

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.2.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 10.1.0.1 0.0.0.0 UG 0 0 0 eth0

in which case all traffic not destined for the 10.2.0.0/16 network will go thru the 10.1.0.1/eth0 interface. I want to be able to have the default route be 10.2.0.1/eth1 interface instead. I have messed around with IPv4 Settings > Routes by trying to add in an override default gateway but nothing seems to work. Also if I disable the interfaces using the applet and renable and from the command prompt continously run netstat -rn I see at first the default route is:
0.0.0.0 10.2.0.1 0.0.0.0 UG 0 0 0 eth1

but then once eth0 interface is brought up it gets overridden. If NM 0.7 is suppose to handle multiple connections it should have functionality to explicitly state which interface is your default if both have equal metrics (eg. both are wired networks) instead of just the second interface to be brought up vi NM.

Here is some more information about network-manager

$ dpkg -l | grep network-manager
ii network-manager 0.7~~svn20081018t105859-0ubuntu2~nm2~hardy1 network management framework daemon
ii network-manager-gnome 0.7~~svn20081012t133407-0ubuntu1~nm1~hardy1 network management framework (GNOME frontend

$ dpkg -s network-manager | grep ^Depends:
Depends: dbus (>= 0.60), hal (>= 0.5.7.1), iproute, iputils-arping, libc6 (>= 2.4), libdbus-1-3 (>= 1.1.1), libdbus-glib-1-2 (>= 0.74), libglib2.0-0 (>= 2.16.0), libhal1 (>= 0.5.8.1), libnl1, libnm-glib0 (>= 0.7~~svn20080908), libnm-util0 (>= 0.7~~svn20080908), libnspr4-0d, libnss3-1d, libpolkit-dbus2, libpolkit2, libuuid1, lsb-base (>= 2.0-6), update-notifier-common, wpasupplicant (>= 0.6.1~)

[Alexander Sack (asac)]

Please file this bug in bugzilla.gnome.org directly as this needs to be fixed there. please give us the bug id, so we can track help to find a solution.

[Jason Kraft (jason-kraft)]

Filed a bug on bugzilla.gnome.org:

http://bugzilla.gnome.org/show_bug.cgi?id=558113

[Tien Nguyen (tienhn)]

I have a similar problem with routing. After VPN PPTP is connected, all default routes go to ppp0 which I do not want. I would like to leave my routes alone and add the VPN subnet to the table. How do I specify this:
X-NM-Routes=192.168.1.0/24

To the new VPN connection?
Thanks for any helps. VPN plug in for network manager is the the most severe bug in my 8.10 upgrade. The rest are great!

Cheers.

[Alexander Sack (asac)]

Tien, maybe the -pptp package from https://edge.launchpad.net/~network-manager/+archive helps you to configure your routes for your ppp stuff?

[Steve Langasek (vorlon)]

I've also run into this in conjunction with bug #320652. At least if the default routes from both interfaces were honored, the severity of bug #320652 would be somewhat lessened - though I would still end up with a broken DNS config.

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

This hould be fixed in Jaunty now. Thanks for reporting.

[Steve Langasek (vorlon)]

It is not. On what basis do you think that it is?

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Uh, sorry Steve, then my presumption was right...

I had a look at the upstream bug, where it says that this is fixed in trunk on 2009-01-16. Then I pulled the network-manager-applet package from Jaunty and went trough the changelog, but couldn't find the regarding bugnumber of the upstream bug. I found that odd, but thought that the fact that the changelog for the package in Jaunty includes fixes up to 2009-02-13 would be enough.

I am very sorry if I was wrong.

[Steve Langasek (vorlon)]

Ok, I've read the description of the upstream fix, and I see the described option present now in the 'Routes' dialog.

I don't think this is a complete fix - it's still a bug that network manager clobbers existing default routes when bringing up a new interface, instead of making both routes available. But I'll file a separate bug report for that.