Network Manager conflict with bridge defined in /etc/network/interfaces

Bug #296782 reported by Sunda Sundaram
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Hi,

I have just set up a bridging on my Kubuntu Hardy Heron system to use VirtualBox in host mode:

$ cat /etc/network/interfaces
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

auto tap0
iface tap0 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
tunctl_user christof

auto br0
iface br0 inet dhcp
bridge_ports eth0 tap0

Everything works fine after executing "/etc/init.d/networking restart". But when I reboot the system, someone (I guess it is the Network Manager) still brings up eth0 with its own IP address configured, although the bridge is also active as defined in /etc/network/interfaces and using eth0 already. To get networking on my host system operational again, I always need to rerun "/etc/init.d/networking restart".

As my setup now already configures eth0 through /etc/network/interfaces for bridging, can anyone tell how to convince the Network Manager to not reconfigure it on boot?

Thanks for any help,

Christof

Revision history for this message
Sunda Sundaram (sunda-mailinator) wrote :

I'm also having this problem.
Any solution for this or is it "working as designed"?

Revision history for this message
Christof Warlich (cwarlich) wrote :

I could finally fix the problem by explicitly adding

auto eth0
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down

to /etc/network/interfaces. Thus, the complete file looks like this:

auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

auto eth0
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down

auto tap0
iface tap0 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
tunctl_user christof

auto br0
iface br0 inet dhcp
bridge_ports eth0 tap0

It seems like eth0 will by default be configured for IP when it is _not_ mentioned
in /etc/network/interfaces, so one must explicitly tell the system _not_ to do so
if this is not desired.

I hope this helps,

Christof

Changed in kde-systemsettings:
assignee: nobody → cwarlich
status: New → In Progress
Revision history for this message
Sunda Sundaram (sunda-mailinator) wrote :

Christof,

Thank you for the workaround but this is not really a fix. This behavior of "DHCP by default" is incredibly faulty. I have 2 interfaces. Both are connected to the same network for specific reasons and due to this weird "feature" everytime I boot I need to shutdown the eth1.

Revision history for this message
Christof Warlich (cwarlich) wrote :

I agree that configuring physical interfaces that are not mentioned in /etc/network/interfaces with DHCP by default is not what most people would expect - it caused some headaches for me at least. It would be a much cleaner approach to implement the "DCHP by default" behaviour by simply adding related DCHP stanzas to /etc/network/interfaces.

But while the current approach may not be ideal, it dosn't prevent users to change the network configuration according to their needs: To pick the example above, where eth1 shall be left unconfigured, the current implementation requires to _add_ a stanza to /etc/network/interfaces that tells the system to leave it untouched, while one would have to _remove_ the DHCP eth1-stanza when the "cleaner approach" suggested above would have been implemented.

Thus, if the definition of "fix" is to solve an issue in the best posible way, I could agree that the above is not a fix, but it' s definitely a good workaround: To avoid the need to shutdown eth1 manually after every reboot, you may just add

auto eth1
iface eth1 inet manual
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down

to /etc/network/interfaces.

Revision history for this message
quikone8 (ron-tolmarket) wrote :

This still seems to be a problem. Does anyone have a good workaround for two cards with static ip's?

Revision history for this message
MichaelE (michael-eitelwein) wrote :

Look at https://bugs.launchpad.net/bugs/256054 - maybe this helps?

Revision history for this message
Christof Warlich (cwarlich) wrote :

Yes, seems to be related. As I'm quite happy with my workaround described above for the time being, I'd be fine to either close this bug report or set it to something like "duplicate to https://bugs.launchpad.net/bugs/256054". Can anyone give advice how to do this?

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Closing this bug as Fix Released as NM is expected to manage devices not configured in /etc/network/interfaces and NM has had some more enhancements of the code to parse that file. AFAIK, eth interfaces should now be ignore when set up in a bridge.

Christof, please just don't assign yourself to bugs unless you're actively working on fixing the issue ;)

Changed in network-manager (Ubuntu):
assignee: Christof Warlich (cwarlich) → nobody
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.