Re: git: b61850c4e6f6 - main - bridge(4): default net.link.bridge.member_ifaddrs to false

On Sun, May 18, 2025 at 07:53:14PM +0100, Jessica Clarke wrote:
> On 17 May 2025, at 22:18, Mitchell Horne <mhorne@freebsd.org> wrote:
> > On 5/14/25 21:04, Lexi Winter wrote:
> >> The branch main has been updated by ivy:
> >> 
> >> URL: https://cgit.FreeBSD.org/src/commit/?id=b61850c4e6f6b0f21b36da7238db969d9090309e
> >> 
> >> commit b61850c4e6f6b0f21b36da7238db969d9090309e
> >> Author:     Lexi Winter <ivy@FreeBSD.org>
> >> AuthorDate: 2025-05-14 14:26:24 +0000
> >> Commit:     Lexi Winter <ivy@FreeBSD.org>
> >> CommitDate: 2025-05-15 00:02:52 +0000
> >> 
> >>    bridge(4): default net.link.bridge.member_ifaddrs to false
> >> 
> >>    As discussed on arch@, this behaviour is broken and confuses users, so
> >>    disable it by default.  For 15.0-RELEASE, allow it to be re-enabled
> >>    using a sysctl, but the sysctl will be removed in 16.0R.
> >> 
> > 
> > Hi Lexi,
> > 
> > I just updated my workstation past this commit. I found that my main
> > ethernet interface didn't receive an IP address, and had to set the
> > sysctl to proceed as before.
> > 
> > I have the following network configuration lines in my rc.conf:
> > 
> >  ifconfig_re0="DHCP"
> >  cloned_interfaces="bridge0 tap0"
> >  ifconfig_bridge0="addm re0 addm tap0 up"
> 
> I also have a setup like this, as I suspect many do.

I do too.

> The handbook even
> gives this configuration in places[1] (though note it’s inconsistent in
> whether the interface or bridge should have the address). The lack of
> interaction with devd to automatically run dhclient as re0 comes and
> goes is also rather sucky, especially if re0 is wlan0. I appreciate
> that there may well be good technical reasons why this shouldn’t be
> what people do, but (a) it is for specifically this case and I think
> it’s a bit shortsighted to go and break something we still document
> today as correct (b) the UX needs improving specifically for bridging a
> real interface to one or more tap ones before we enforce this.

I agree.  Even if the setup is broken in some way, it works fine for
simple cases and this will be a nasty surprise when upgrading.

It would be much better IMO to print a warning and let users fix their
configuration before flipping the default.  That is how we handled
interface address configuration without a netmask: commit d8237b955528
added a warning, and some time later it was turned into a fatal error.
I really think it would be better to do something similar here.