Hi! I think that what may be happening is that the bridge interface is coming up before the ethX interface is available, thus bridge-utils cannot attach it to the interface.
To know for sure if this is happening, we need to get the output of some commands after the system is up and without running any scripts or daemons that may touch the network status. Please try to run: brctl show ifconfig If the bridge is up but the ethX interface is not attached, we can try something: bridge-utils now has some hotplug capabilities, by default they are off, but we may need to turn them on, to do this edit /etc/default/bridge-utils and set BRIDGE_HOTPLUG to yes, then try to boot again with this new setup and after booting run again brctl show;ifconfig and send the results. I really didn't understand all your report, please try to be clear and try not to mix NM or any other external stuff at first, if this stuff is really messing up bridge-utils setup we'll bring them in at the end when we know your setup works ok without the extra stuff. Thanks in advance. On Oct 13 2014, westlake wrote: > " > # The loopback network interface > auto lo > iface lo inet loopback > > # The primary network interface > #allow-hotplug eth0 > #iface eth0 inet dhcp > > iface eth0 inet manual > > auto br0 > iface br0 inet dhcp > bridge_ports eth0 > bridge_stp off > bridge_waitport 0 > bridge_fd 0 > bridge_maxwait 0 > #bridge_hw > " > > > I noticed two systems running Jessie. The setup for Station 1 with > the above interfaces works without issue, but Station 2 currently > has a problem with "iface br0 inet static" > > Station 2 I'll be referring to even though I've managed a > workaround. I show the workaround I use. I'll also give a little > note here before diving into this.. > > A little story here before setting up a bridge device, since my time > with testing Jessie few weeks ago I noticed that systemd(or > "something" with networking, I'm making sure I'm not using NM with > these server machines), the "allow-hotplug eth0" is necessary for > eth0 to work properly on bootup. In other words, > > [Tested on Station 1] > a) > "allow-hotplug eth0 > iface eth0 inet dhcp > " > , or > > b) > ""allow-hotplug eth0 > iface eth0 inet dhcp > " > > is not good enough, but > > "allow-hotplug eth0 > auto eth0 > iface eth0 inet dhcp > " > > gets eth0 working with dhcp as intended > > I'm assuming a) is not an issue with NM because NM would require the > ifupdown plugins with a managed= directive in networkmanager.conf.. > > Substracting NM, now looking at setting up bridge br0 on the > Station2's "inet br0 static" configuration.. You are right > allow-hotplug is not needed for br0(and neither should it be with > inet br0 dhcp, which I approve as correct on Station 1's example) > but there's something broken to having bridging working properly > with "iface eth0 static"(Station 2) which is I'm bothering to throw > in allow-hotplug with br0. > > ^ If you can explain to me why "allow-hotplug" is needed for the > non-bridge eth0 setup that I'm interested after, so I can only > speculate it would also be needed without harm for trying with br0 > as well. But here again I know "iface br0 static" on station 1 does > not need it. > > > The station 2 configuration file I have for its interfaces: > "allow-hotplug eth0 > #auto eth0 > iface eth0 inet manual > #pre-up /sbin/ip link set eth0 address 70:54:d2:19:69:f7 > up /sbin/ip link set eth0 up > pre-down /sbin/ip addr flush dev eth0 > down /sbin/ip link set eth0 down > > > #allow-hotplug br0 > auto br0 > iface br0 inet static > bridge_ports eth0 > bridge_ .. > address <> > netmask <> > network <>192.95.29.0 > broadcast <> > gateway <> > " > > The workaround I use is with /etc/rc.local > " > /sbin/ifup eth0 > /sbin/ip link set eth0 up > /sbin/ifup br0 > exit 0 > " > > > And yes, you'll just say it all has to be set properly in the > interfaces and one should be using "auto br0" to have it load > automatically on boot-up. Unfortunately this is not happening > otherwise I would of solved it quite easily. The Station 2 is a > completely new install of Debian Jessie on a "remote" system. It was > actually hard for me to diagnose remotely it so I got leased a > KVM-over-ip for a day and I know what I'm filing here is as accurate > as I can possibly describe because I really wish somebody can fix > this with due all respect (if you don't mind me saying because I > really want to get to why this is happening! :). > > I went to setup a KVM on a local station(Station 1) here from > scratch and tested "iface br0 inet dhcp" without issues.. And not to > add to any confusion here, I went ahead with another test on Station > 1 using "iface br0 inet static" and it definitely works.. so why oh > why is it not working on Station 2? > > They both are loading the "bridge" module (and needless to say I > don't even think they need it? I do know iproute2/"ip bridge" adds > more port features to the traditional bridge devices.) > > So what is the problem with bridge-utils? Can it be using a > problematic probe tool causing it not to work with e1000e nic > interfaces? A few days ago I installed "ethtool" to see if anything > of ifup's scripts was problematic without it. Could it be a > "hardware" issue? I don't think so because I can just issue "ifup > eth0, ifup br0" from /etc/rc.local and it works properly (why > ethtool? because I noticed one of the ifup scripts was scanning for > ethtool and thought it can ameliorate something to do with Station'2 > particular e1000e driver. It generates the file > /etc/network/if-up.d/ethtool) > > The system on Station 2 was setup from scratch by me with a debian > jessie installer. I'm sure something is broken somewhere but I don't > know where to look.. > > Also if anyone knows as to why > "allow-hotplug eth0" is needed for an eth0-only connection, I'm > interested on this as well, I suppose if it is not needed then I > would have to file a bugreport about this because over here when > testing things I actually needed to use it. > > If this sounds complicating then I apologize, I've been on this over > the weekend and right now br0 is being loaded up properly with that > rc.local workaround when I know this is not the "perfect fix" so > there's definitely a bug somewhere. Let me me know what I should try > next and I'll do my best to see if I can manage things without too > much disruption.. > > thanks -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
