Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

From: Marek Zarychta <zarychtam_at_plan-b.pwste.edu.pl>
Date: Mon, 19 May 2025 09:54:28 UTC
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