Robert Swindells <rjs%fdy2.co.uk@localhost> writes: > Staffan Thomén <staffan%shangtai.net@localhost> wrote: > >>brconfig bridge0 add wm1 stp wm1 add wm2 stp wm2 add wm3 stp wm3 >> >>This all works, packets flow and addresses are learned on all >>interfaces, but ONLY if there is a cable with a link on wm1. It seems to >>be that if there is no link on wm1 the interface (status: no carrier and >>address shows <DETACHED>) gets disabled in the bridge, which kind of >>sucks because then the host has no address and communication stops. > > [snip] > >>So how is this supposed to work? Can I force the interface with an >>address to stay enabled somehow or is there a pseudo-device that I >>haven't found that I should be using? > > My reading is that this is caused by revision 1.175 of if_bridge.c which > explicitly changed bridge(4) to behave in this way. I can see the point of considering an address detached if link is down and it's from DHCP. For static, I don't understand the reasoning. bridges are a layer2 thing; they shouldn't care about the presence of IP addresses. > I have been caught out by this change in a different way. I just use > dhcpcd(8) to configure IPv6 and have static IPv4 addresses on everything > on my LAN. > > When I add the upstream interface to a bridge this toggles the status > on the interface and something in dhcpcd(8) or resolvconf(8) overwrites > my /etc/resolve.conf with an empty one. That seems like a different issue. If you want dhcp processing to only set resolv.conf when hearing on one particular interface, you should be able to configure it. But maybe I'm just not following.
Attachment:
signature.asc
Description: PGP signature