From nobody Mon May 19 09:54:28 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b1Chj6xxYz5wrPy for ; Mon, 19 May 2025 09:54:45 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b1Chj5929z3TWZ; Mon, 19 May 2025 09:54:45 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [IPV6:2001:678:618:402f:b479:6983:b494:3b10] ([IPv6:2001:678:618:402f:b479:6983:b494:3b10]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 54J9saGP040517 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 19 May 2025 11:54:37 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1747648477; bh=y530LjsCcnpTeCi9PiABHTIVuItqN6p464kssISAVXY=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=NiUolhfspoiDSiYOR/mX0VrX41XgzEO6FIf4qo8FDIO0MK2Y0orLzlcdFIWSPZCVI GutHta8uWEp9ihixRJpR2FBFr88UMEP/hm7fK3dz9SW/5BYpMP8pqd72NJ87MJeSGS Rke9svgYCfPJXAu1Ir+wpyPJc8jd5Xitr4ISPCiCUNlUEtNfCZmC4jDzmbf7e5jm8J mH7g7O3gxLoVPqn+JM2NpLaWA7g6Dqc3vUlk7SisRBJtGPOJjxorS+GtnEha216qGQ GxDBilD/oMb0+F4MuiEPiARlrYcWdXevDTo7wZMHUEzPPbWvxmCrpR6cfBzhMIytYE ebTy6Xghktueg== Content-Type: multipart/alternative; boundary="------------g0oroke8V4PaanluqcQ1YgF8" Message-ID: <9ba436fb-4fdd-4f05-b92d-0704a2d203a3@plan-b.pwste.edu.pl> Date: Mon, 19 May 2025 11:54:28 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument To: Kristof Provost Cc: Alexander Leidinger , A FreeBSD User , rgrimes@freebsd.org, FreeBSD CURRENT References: <20250518180658.2e58d55a@thor.sb211.local> <192c8e37-4a85-4916-9986-0a556333a527@plan-b.pwste.edu.pl> <20250518182404.3a760da9@thor.sb211.local> <1ca30cdfb783848eafce24b77f10c0a5@Leidinger.net> <310d460a-d372-47c8-8275-2908bb8417ad@plan-b.pwste.edu.pl> <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> Content-Language: en-US From: Marek Zarychta In-Reply-To: <7A4E0DDE-77F7-4CDC-8C52-BE938298E105@FreeBSD.org> X-Rspamd-Queue-Id: 4b1Chj5929z3TWZ X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL] X-Spamd-Bar: ---- This is a multi-part message in MIME format. --------------g0oroke8V4PaanluqcQ1YgF8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit W dniu 19.05.2025 o 10:43, Kristof Provost pisze: > On 18 May 2025, at 21:24, Marek Zarychta wrote: >> W dniu 18.05.2025 o 19:48, Alexander Leidinger pisze: >>> You want to make it work without this. Short: use the IP on the bridge itself, not in the member IF. >> I'm not sure we should be dictating to Oliver what he must do. > Oliver is of course free to solve his problem however he wishes, but setting the sysctl is the worst option available. This will break again later, and will continue to break multicast. > > The usual warranty applies: you get to break your own systems however you like, and you even get to keep all of the pieces afterwards too. > >> There are multiple possible solutions. One could, for example, use ng_bridge(4), or take yet another direction entirely. Users should be free to experiment and work flexibly with the operating system. Forcing everyone to move all their addresses to the logical bridge(4) interface seems like it narrows the range of valid deployment scenarios for bridge(4) >> > What specific scenario does not work with the address assigned to the bridge rather than a member interface? It's a temporary bridge, but that’s not really the issue. Perhaps the way this change was introduced caught some people by surprise. > >> That said, is the fact that a few users are experiencing issues with multicast between interfaces connected to a bridge - or that they struggle to migrate addresses onto the bridge interface - really a sufficient reason to prohibit everyone from assigning addresses to bridge members? >> Multicast does work. It just doesn’t work between bridge members. Maybe someone will fix that someday. > It’s been broken for years, and no one has fixed it so far. All of the people who have done actual work on the if_bridge code (e.g. myself and Ivy) are telling you this configuration is broken and will not be supported. > >> Back to Cy Schubert’s thread about epair(4), which touches on this issue: what's striking is that this change doesn’t just shoot users in the foot, it shoots and surprises committers as well. Committers who, well, will grit their teeth and defend the change regardless. >> > And this is exactly why Ivy’s change is good. Users have been shooting themselves in the foot for years. We’re making that impossible. > >> I do miss people like the late Mike Karels, who would have made a clear and confident decision about how this should be handled. >> > That decision has been made. > >> Where is the Janitor? Mr Grimes -  where are you? >> >> As a user with 30 years of experience with this OS, allow me to ask: who’s actually in charge of all this now? > As always: the people actually doing the work. > > — > Kristof Thanks for stepping in Kristof. It's good to hear that everything is under control. The change seems well justified - and perhaps even a bit overdue. Let’s hope it brings a noticeable improvement to the user experience. Kind regards, Marek --------------g0oroke8V4PaanluqcQ1YgF8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

W dniu 19.05.2025 o 10:43, Kristof Provost pisze:

On 18 May 2025, at 21:24, Marek Zarychta wrote:

W dniu 18.05.2025 o 19:48, Alexander Leidinger pisze:

You want to make it work without this. Short: use the IP on the bridge itself, not in the member IF.

I'm not sure we should be dictating to Oliver what he must do.

Oliver is of course free to solve his problem however he wishes, but setting the sysctl is the worst option available. This will break again later, and will continue to break multicast.

The usual warranty applies: you get to break your own systems however you like, and you even get to keep all of the pieces afterwards too.


There are multiple possible solutions. One could, for example, use ng_bridge(4), or take yet another direction entirely. Users should be free to experiment and work flexibly with the operating system. Forcing everyone to move all their addresses to the logical bridge(4) interface seems like it narrows the range of valid deployment scenarios for bridge(4)


What specific scenario does not work with the address assigned to the bridge rather than a member interface?
It's a temporary bridge, but that’s not really the issue.
Perhaps the way this change was introduced caught some people by surprise. 


That said, is the fact that a few users are experiencing issues with multicast between interfaces connected to a bridge - or that they struggle to migrate addresses onto the bridge interface - really a sufficient reason to prohibit everyone from assigning addresses to bridge members?
Multicast does work. It just doesn’t work between bridge members. Maybe someone will fix that someday.

It’s been broken for years, and no one has fixed it so far. All of the people who have done actual work on the if_bridge code (e.g. myself and Ivy) are telling you this configuration is broken and will not be supported.


Back to Cy Schubert’s thread about epair(4), which touches on this issue: what's striking is that this change doesn’t just shoot users in the foot, it shoots and surprises committers as well. Committers who, well, will grit their teeth and defend the change regardless.


And this is exactly why Ivy’s change is good. Users have been shooting themselves in the foot for years. We’re making that impossible.


I do miss people like the late Mike Karels, who would have made a clear and confident decision about how this should be handled.


That decision has been made.


Where is the Janitor? Mr Grimes -  where are you?

As a user with 30 years of experience with this OS, allow me to ask: who’s actually in charge of all this now?

As always: the people actually doing the work.

—
Kristof

Thanks for stepping in Kristof. It's good to hear that everything is under control.

The change seems well justified - and perhaps even a bit overdue. Let’s hope it brings a noticeable improvement to the user experience.

Kind regards,
Marek

--------------g0oroke8V4PaanluqcQ1YgF8--