Hi, thank you for looking into this! Sorry for not responding to your previous mail (I really didn't have anything to add at that point though).
On Sat, 7 Dec 2013 01:35:37 +0100 Santiago Garcia Mantinan <[email protected]> wrote: > While I was investigating your suggestion I realised that if I set > the hw address with > ip link set dev br0 address whatever > then the address is preserved no matter what cards are attached to the > bridge, thus doing what you want without needing to change the way on > which we create the bridge. I agree that this would be the preferable way. > So, what I'm thinking on doing is to set the hardware address like > that on the next version of the package, instead of playing with the > address of the nics, which was a little bit dirty anyway. > > Can you check if this works for you? Unfortunately it doesn't, see the output below: # brctl addbr br2 # ip link set br2 up # ip address show dev br2 16: br2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default link/ether e6:0f:87:cc:8b:a6 brd ff:ff:ff:ff:ff:ff inet6 fe80::e40f:87ff:fecc:8ba6/64 scope link valid_lft forever preferred_lft forever The bridge interface reports state UNKNOWN, but is really up (and also has an IPv6 link-local address). # brctl addbr br2 # ip link set address fe:9e:82:a8:a0:4b dev br2 # ip link set br2 up # ip address show dev br2 17: br2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether fe:9e:82:a8:a0:4b brd ff:ff:ff:ff:ff:ff The specified MAC address is correctly set to the bridge interface, but the state is DOWN (and no IPv6 link-local address is present). In this state the bridge is unusable for VirtualBox VMs. # ip link add br2 address fe:9e:82:a8:a0:4b type bridge # ip link set br2 up # ip address show dev br2 18: br2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default link/ether fe:9e:82:a8:a0:4b brd ff:ff:ff:ff:ff:ff inet6 fe80::fc9e:82ff:fea8:a04b/64 scope link valid_lft forever preferred_lft forever This reassembles the output of the initial set of commands with the correct MAC address set. This way my VirtualBox VMs can use the bridge without any problems. We'd probably have to look at the kernel code to find out the reason to this (seemingly strange) behavior. My guess is that the VirtualBox kernel module is really to blame because the VMs can use the bridge but `brctl show` doesn't show any associated interfaces. This could mean that the kernel isn't properly informed that the bridge is actually being used. But again, I'm just guessing here. I can understand that you are reluctant to change the way the bridge interfaces are created. I initially opened this wishlist bug not only because I could solve my (probably not very common) problem but also because `man 5 bridge-utils-interfaces` suggests that the maintainer is unhappy with the way the bridge_hw option works. Your proposed solution makes a lot more sense compared to setting the hw address of all participating NICs. So if you're happy with that feel free to implement it. I can easily implement my workaround by using the pre-up/post-down options to create/destroy the bridge using the iproute2 tools. I hope this information is helpful to you. Thanks again for your time and effort! Regards Lukas
signature.asc
Description: PGP signature
