Date: Sun, 18 May 2025 21:30:55 +0100 From: Jessica Clarke <jrtc27@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: Mitchell Horne <mhorne@freebsd.org>, Lexi Winter <ivy@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org> Subject: Re: git: b61850c4e6f6 - main - bridge(4): default net.link.bridge.member_ifaddrs to false Message-ID: <82C39393-F26D-4E7B-B62A-5CC9C85BAD1A@freebsd.org> In-Reply-To: <aCpBp5MhoiBCSA5y@nuc> References: <202505150004.54F04FhR046897@gitrepo.freebsd.org> <d839f137-b43b-416b-968f-439301f0a5c6@freebsd.org> <E0215FA7-F317-48EE-954C-15B0FA0ED7F3@freebsd.org> <aCpBp5MhoiBCSA5y@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>>>=20 >>>> URL: = https://cgit.FreeBSD.org/src/commit/?id=3Db61850c4e6f6b0f21b36da7238db969d= 9090309e >>>>=20 >>>> 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 >>>>=20 >>>> bridge(4): default net.link.bridge.member_ifaddrs to false >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> Hi Lexi, >>>=20 >>> 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. >>>=20 >>> I have the following network configuration lines in my rc.conf: >>>=20 >>> ifconfig_re0=3D"DHCP" >>> cloned_interfaces=3D"bridge0 tap0" >>> ifconfig_bridge0=3D"addm re0 addm tap0 up" >>=20 >> I also have a setup like this, as I suspect many do. >=20 > I do too. >=20 >> The handbook even >> gives this configuration in places[1] (though note it=E2=80=99s = 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=E2=80=99= t be >> what people do, but (a) it is for specifically this case and I think >> it=E2=80=99s 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. >=20 > 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. >=20 > 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 =E2=80=9CI = want a tap interface for a VM=E2=80=9D and =E2=80=9CI want devd+dhclient to = manage DHCP for me automatically=E2=80=9D 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=E2=80=99re 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?82C39393-F26D-4E7B-B62A-5CC9C85BAD1A>