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

On 18 May 2025, at 21:23, Mark Johnston <markj@freebsd.org> wrote:
> 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.

That would go some way to helping, but I really do not want “I want a
tap interface for a VM” and “I want devd+dhclient to manage DHCP for me
automatically” to be incompatible, which based on the thread here it
sounds like they are. Somebody needs to fix that before we even warn
users not to do what they’re doing, let alone make it an error.

Especially given that SYNCDHCP is not compatible with WPA, given that
just runs wpa_supplicant as a daemon and relies on that later
triggering dhclient?

Jess