Dear Maintainer,

ifupdown depends on brctl, but should use ip instead

reassign 939713 bridge-utils
thanks

The ifupdown package itself doesn't provide any support for bridge
interfaces, nor does it depend on brctl. It's the bridge-utils package
that provides a plugin for ifupdown to support bridge interfaces,
therefore I'm reassigning this bug report to the bridge-utils package.

I'm aware ip has taken over the functionality of many other network
utilities. If it provides all the functionality of brctl, perhaps the
bridge-utils package could start using ip command in
/etc/network/if-*.d?

On Fri, 20 Sep 2019 16:32:03 +0200 Guus Sliepen <
guus@debian.org
package
package.

Hello Sergio,

Sorry, I'm not following - why the reassignment from bridge-utils to
iproute2? What's the ask here?

Thanks!

bridge-utils already provides if-{pre|post}-up.d/bridge and iproute2
does not.

Hello,

I'm going to reassign this back to where it originally came from,
ifupdown.

My opinions is that bridge-utils is deprecated and should eventually
get removed. (The sooner the better.)

As previously suggested bridge-utils /could/ ports its ifupdown hooks
over to use iproute2, but as I'm personally not a fan of micro-packaging
keeping the bridge-utils package around simply for the ifupdown hooks
does not sound like a good plan to me. (The current hooks
implementations also seems to have limitations that one might want to
adress in a newly designed solution.)

The iproute2 package also can't ship the same ifupdown hook files as
bridge-utils does as that would be a conflict. And even if the conflict
was specified via the Conflicts: control keyword that still wouldn't
work as files under /etc are dpkg conffiles. The files could ofcourse
have a different name under iproute2 but then you would also need to
handle the case when both iproute2 and bridge-utils provides the same
hooks (with different names) and avoid both of their functionality
colliding mid-air. I simply don't find this compelling to pursue.

I'm also going to state that iproute2 is a package with (only) low level
networking utilities. It is not the right place to implement higher
level (ifupdown) functionality. The iproute2 package does not ship any
kind of policy on how the tools should be used (eg. init scripts, etc.),
it simply provides a mechanism which other higher level packages can
use to implement their policy.

The ifupdown implementation already heavily relies on iproute2 and
changing that would be a big undertaking and isn't going to change any
time soon as far as I can predict. If someone wants bridge support in
ifupdown, then I'd suggest the correct place to implement that would be
in the ifupdown package itself. The functionality is already at
ifupdowns fingertips as the already existing dependency on iproute2
also gives the bridge command. Spreading ifupdown implementation over a
wide range of packages is in my opinion a mistake. I also think the
hooks are an often overused way of working around missing functionality
in ifupdown that is better adressed by implementing it properly in
ifupdown if so desired.

I personally think that networking tools that wants to be something to
count with needs to be able to speak netlink (and listen to events). I
don't see ifupdown as part of a future vision. It's mainly filling the
need of being a widly documented way of setting up basic networking. As
time passes I hope documentation for more modern solutions will be more
pervasive and the need for keeping compatibility with
/etc/network/interfaces hopefully diminish. The iproute2 suite can be
used for simpler "one off" tasks (which higher level networking policy
tools should see via netlink events). With all this in mind, I think
this is yet another reason why iproute2 should not get involved in
ifupdown business (or in any other way widen its scope). Specially since
getting people interested in helping out with iproute2 package
maintenance has unfortunately proven harder than desired despite its
very wide usage. In my opinion someone who wants to rely on advanced
functionility like bridging should probably be looking for an
alternative to ifupdown. I personally wouldn't mind this bug report
simply being tagged wontfix (and closed) in a self-deprecating kind of
way if ifupdown maintainers thinks bridging is not something they
want to support.

Apart from the reasons already stated above, I think the original
description fits well with this being an ifupdown feature request
(rather than any other alternative view of how to interpret this as has
been done during the following reassignings).

Regards,
Andreas Henriksson

As stated in many different places, bridge-utils has long been deprecated and ought to be replaced with built-in support for the "bridge" command in iproute2 instead.

The syntax I would propose for interfaces:

iface br0 inet METHOD
	address (IP address, if METHOD other than dhcp)
	hwaddress (default: random, or specify MAC address)
	bridge ("all" or space-separated list, may include /en* wildcards)

This would also bring the syntax for bridges in line with what ifupdown already uses (bridge-utils deviates from this for a number of options).

ifupdown already Depends on iproute2, so this should be fairly straightforward.

- -- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'testing')
Architecture: i386 (i586)

Kernel: Linux 5.18.0-1-686 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ifupdown depends on:
ii  adduser   3.121
ii  iproute2  5.18.0-1
ii  libc6     2.33-7
ii  lsb-base  11.2

Versions of packages ifupdown recommends:
ii  dhcpcd5 [dhcp-client]  9.4.1-0.1

Versions of packages ifupdown suggests:
ii  ppp     2.4.9-1+1.1+b1
pn  rdnssd  <none>

- -- debconf information:
  ifupdown/convert-interfaces: true
  ifupdown/convert-interfaces-hotplug: true
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmKp8zMACgkQrh+Cd8S0
17a+ABAAhKlvHzsvCDJAbqSTi6Lt/6JAk7C0p2vSCqEASnT0RlQGx+eEnHeue73T
ulH0L9D4m5V9Va4gxiJJDNxXHKi6a5Fl08uRR3+tVLFXswq2IIucnZPhwurJ6Rqx
gCKkHLWz1pNiWlMMhj5YFSrpxGrAaHzhbR0oEg5Ja//QIwNTWgGhyVCB8ibJV63i
vPReuJfwc7xtwghcO9QCJKyQG98d/oqoiqhySaT8kUaMWi2pIC0OpLit5af07jpd
J381SVGs6SCG6h0CJGRwYaL/hZls0t716Tq+AF2P1t8/7b4ruQp2n2hL/bNz+uZg
7zlRo/wFvneuAMhwlPnE+5a5eISL1JVBKK4Dr39jXdy8SfhbTP2H+zL/xl6WPMAr
9zv1nWZpykFkwrbNq8lQnso7R+r6PKcluBdguu19AnpA8LivoXnk0JbF01p1z9Ys
+0FJJqjey5GeThW7w9V4x/ldQw8KtRvwCs1/58qUcYdKvAJrSugv59WFq4IkgdN6
+zYxe5vZhd08aPh0Amt8QxYze3yC8y0z6juF/DI2ev6xavYjW+RG6/U9WKCLKBQu
pmz3+8t3YaHu523VNxBSdx9LFdTAfBsajJPcg8VjuG2V8Csn9sGl+EXMRcevyYvs
NOO4zDTShmdcXzE+u2wPu4JEt9cyM/XRuvytOt4Qswp1GkX+4wg=
=rssa
-----END PGP SIGNATURE-----

Howdy!

Is there any news on this?

Getting rid of the deprecated bridge-utils and implementing support for setting up bridges using 'ip' from iproute2 (ifupdown already depends on this) would be extremely desirable.

Martin-Éric

- -- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages ifupdown depends on:
ii  adduser   3.137
ii  iproute2  6.9.0-1
ii  libc6     2.38-13

Versions of packages ifupdown recommends:
pn  isc-dhcp-client | dhcp-client  <none>

Versions of packages ifupdown suggests:
pn  ppp     <none>
pn  rdnssd  <none>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZ1PKwACgkQrh+Cd8S0
17ZufRAAgyLP5+ph2ujHmf2638K0pqG5vb4fk6gXlkMOvo/Idvgh3PvZW4Y/lfg3
1ajcfz4oXeh+W2SpJJKQeP+vvfGdjm3EEytsI5ry0E5NkDJOP2A9jLOMO1LGcGXO
u/3r1U16ydHDZTku2WZWIU7E1kxAza2hCE4K1jVgZXvFeIPkxZB6EjfZE1cSgtt0
RZSRDF33bH0WM5ERzvvKt7vZ94w2qrcAmq7QEuq8qEuBv16zZT18nogwlQRcjCYh
VKgNMvGyqCjpPwDfSgmNWQN2J2XD45T2DOrQC/RlWcFW3rYFXYvHHnnur22b57Lv
ZYdnxJBT/jX9fHVjieV/LaQwnF6R2Z80LajzYfFC4uyx9TQ31eswlf6hKA0TVn5G
fVPZ9r57ycRMxf7nBxoghbXPTRMGFBzb1IhxLibz+rFyyxJmmLD5qcq9l44ZTTi2
BOaeMyQqMsqhEXnvN907A9KamD0tFeYoWSk38XXRqQTY0UgbIndHt5gzZb8OdGEN
VuHyDGSHALhR8NqZTFIMT2Whg67MMG7fmc+lfDf+gIZOR945fJx+2nP453HJfqOI
Vt+YxA2s/9R+K4TFdePlXgdZ2r1AARO/5aXM6vnaY80HhDmsvLG+/rbr0+wsrGQi
6FM1p8Tw623c5NEVsv96FWWwDZLukpkuf/vY2DOpBeEn6OSoWHE=
=U5PH
-----END PGP SIGNATURE-----

Howdy!

Could we possibly get around this before the Trixie freeze?

Thanks!
Martin-Éric

Returning to this issue, now that ifupdown finally has an active developer. Thanks Daniel for picking this up.

Deprecating bridge-utils and implementing support for bridge creation using the 'ip' command as a backend within ifupdown remains a highly desirable goal.

Martin-Éric

Control: retitle -1 ifupdown: Add support for iproute2 bridge
Control: tags -1 + wontfix

I don't expect this will happen in traditional ifupdown.

ifupdown-ng already has iproute2 `bridge` support see
https://manpages.debian.org/trixie/ifupdown-ng/interfaces-bridge.5.en.html

and the implementation

https://github.com/ifupdown-ng/ifupdown-ng/blob/main/executors/linux/bridge#L126C1-L126C25

Let me know if you find anything missing or wonky so I can add it to my
compat TODO list.

I don't see the pressing need, can you explain the motivation? I don't
personally use bridges very much.

ti 11.11.2025 klo 2.21 Daniel Gröber (dxld@darkboxed.org) kirjoitti:

Why not?

I'll take a look later.

1) It's long been requested. 2) It's needed  to group several PHY
under one interface. It's pretty much a must for routers. 3)
bridge-utils is buggy and no longer maintained upstream.

Martin-Éric

Moving to ifupdown-ng is the strategy that was agreed upon among the people
doing the work. Please refer back to
https://lists.debian.org/debian-devel/2024/07/msg00098.html#:~:text=ifupdown-ng
for (some) reasoning and the DC25 Networking BoF for some more discussion
https://meetings-archive.debian.net/pub/debian-meetings/2025/DebConf25/debconf25-124-networking-bof.vp8.webm.

I'm not aware of any high-priority issues with bridge-utils. Could you be
more specific?

I do understand the basic bridge use-case.

What I don't see is why replacing bridge-utils (brctl) should be of such
priority that we need to do it *right now* in ifupdown rather than just
wait until it's replaced by -ng?

ti 11.11.2025 klo 13.39 Daniel Gröber (dxld@darkboxed.org) kirjoitti:

There was no agreement on the mailing list.  The BoF wasn't accessible
to many interested parties.

1) It has widely different behaviors depending on whether the bridge
is started via allow-hotplug or via auto.
2) The aforementioned inconsistency with LL6 has long remained unsolved.

1) It was requested ages ago, back when it became clear that
bridge-utils was deprecated, and has remained unanswered since then.
Just look at the thread.
2) We need something that works in a predictable and consitent way now.
3) ifupdown-ng has changed some of the configuration syntax, so it
cannot replace ifupdown.

Martin-Éric

Hi Martin,

If you watch the BoF you'll find no formal decisions were made, but people
got to discuss their high level concerns.

We would have loved to hear your perspective but unfortunately you chose
not to join the BoF remotely. Keep in mind that despite lack of DC video
team coverage in our room Me and Lukkas scrambled to put together a video
call and recording setup last minute amidst a packed conference schedule
essentially just for you.

You ended up choosing not to participate.

Martin. Keep in mind Debian is a do-ocracy. I'm merely informing you the
people doing (or having done) the doing are headed this way. If you
disagree with this strategy you should feel free to do your own work and
present it as an alternative.

Given the growing (*cries*) number of items on my -ng compat TODO list it
may yet be a while until we feel ready to make the change, but once we are
ready we'll certainly send an announcment about it to d-devel before
uploading to unstable given this is a major change.

Different how? What's the user impact?

I don't see how that could have any real world impact. Can you refer me to
any reports demonstrating a problem other than aesthetics?

I have no particular interest in the bridging area at the moment as I've
said. Despite this I'm giving you the opportunity to bring important issues
to my attention here, but so far all I see is opinion and no technical
substance. Bugx or it didn't happen as the kids like to say :D.

We've discussed this before and you neglected to point out any concrete way
in which this is the case. I expect it actually fixes your issues with at
most minor changes in the compatibility code.

Have you considered trying ifupdown-ng and reporting bugs to demostrate
your point?

ti 11.11.2025 klo 15.10 Daniel Gröber (dxld@darkboxed.org) kirjoitti:

That's incorrect. Until the very last minute, it was stated that there
probably won't be a remote possibility, even though someone would try
to see on-site with the organizing team if this could be arranged
after all. I never heard back on that.

It's right there in the thread you quoted above. Santiago said that he
agrees that -ng has a cleaner architecture but switching would require
-ng factually being a drop-in replacement. It clearly isn't, as the
older thread we had on that topic clearly exposed.

Martin-Éric