#110 bridge-utils (for 'brctl') is deprecated upstream

[david M brooke]

The bridge.lrp Package, which uses bridge-utils to implement the brctl command has been declared obsolete as per https://wiki.linuxfoundation.org/networking/bridge which says:

Note: the bridge-utils package is DEPRECATED, instead use the bridge command from iproute2 package.

We already have iproute2 as a Source package (e.g. for tc.lrp) so we could change that to generate the new 'bridge' command too.

The main question is how we structure - and how we name - the resultant LRP Package:
* If we remove the existing bridge.lrp (containing the 'brctl' command) and replace that with a new bridge.lrp (i.e. the same name as today but containing the 'bridge' command instead) might that break things for some users?
* If we create a bridge2.lrp containing the 'bridge' command (the '2' being a reference to iproute2) - and leave the existing bridge.lrp in place for now, would that be better? That's probably more confusing in the long term though.

The scripts (such as 'bridge_if-up') in the existing bridge.lrp (which reference the 'brctl' command) would need some consideration too.

(If we choose to retain brctl / bridge-utils, there's a new version available from https://mirrors.edge.kernel.org/pub/linux/utils/net/bridge-utils/ - we currently use v1.5 which must be very old, since v1.6 dates from 2016 and there's a v1.7.1 which dates from 2021)

[Erich Titl]

Hi David

Am 03.08.2024 um 11:08 schrieb david M brooke:

---

[tickets:#110] https://sourceforge.net/p/leaf/tickets/110/
bridge-utils (for 'brctl') is deprecated upstream

Status: new
Milestone: Bering-uClibc 7.2.x
Created: Sat Aug 03, 2024 09:08 AM UTC by david M brooke
Last Updated: Sat Aug 03, 2024 09:08 AM UTC
Owner: nobody

The bridge.lrp Package, which uses bridge-utils to implement the brctl
command has been declared obsolete as per
https://wiki.linuxfoundation.org/networking/bridge
https://wiki.linuxfoundation.org/networking/bridge which says:

Note: the bridge-utils package is DEPRECATED, instead use the bridge
command from iproute2 package.

We already have iproute2 as a Source package (e.g. for tc.lrp) so we
could change that to generate the new 'bridge' command too.

The main question is how we structure - and how we /name/ - the
resultant LRP Package:
* If we remove the existing bridge.lrp (containing the 'brctl' command)
and replace that with a new bridge.lrp (i.e. the same name as today but
containing the 'bridge' command instead) might that break things for
some users?

I would guess so, unless we provide an intelligent post-upgrade to the
upgrade utility. Breaking bridge could potentially break access to the
box, e.g. brick it.

• If we create a bridge2.lrp containing the 'bridge' command (the '2'
  being a reference to iproute2) - and leave the existing bridge.lrp in
  place for now, would that be better? That's probably more confusing in
  the long term though.

And then bridge3, bridge4 ....

The scripts (such as 'bridge_if-up') in the existing bridge.lrp (which
reference the 'brctl' command) would need some consideration too.

Absolutely

(If we choose to retain brctl / bridge-utils, there's a new version
available from
https://mirrors.edge.kernel.org/pub/linux/utils/net/bridge-utils/
https://mirrors.edge.kernel.org/pub/linux/utils/net/bridge-utils/ - we
currently use v1.5 which must be very old, since v1.6 dates from 2016
and there's a v1.7.1 which dates from 2021)

This at least would/should not break existing configurations. Then of
course some careful consideration should be done to either wrap the new
tools or allow an easy migration.

I have not looked in the new interfaces but would ifup/ifdown work the same?

cheers

ET

--
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

[david M brooke]

Hi ET,

Thanks for your input.

I have not looked in the new interfaces but would ifup/ifdown work the same?

I believe so - in fact I think we need to require that. We would want to make sure that the existing syntax in /etc/network/interfaces works as today. As long as we can arrange that, the only users impacted would be those which call 'brctl' from their own scripts.

dMb

[Erich Titl]

Hi David

Am 07.08.2024 um 17:37 schrieb david M brooke:

Hi ET,

Thanks for your input.

I have not looked in the new interfaces but would ifup/ifdown work
the same?

I believe so - in fact I think we need to require that. We would want to
make sure that the existing syntax in /etc/network/interfaces works as
today. As long as we can arrange that, the only users impacted would be
those which call 'brctl' from their own scripts.

Which is probably a minority. Now I would argue that we should leave the
name convention for the bridge package as is, e.g. bridge.lrp. I read
that the functionality should be / is moved to the ip command, so
basically the interface would be a wrapper.

Looking at my currently running box (7.1.0) ip appears not to have this
capability but maybe my test is bogus or I should upgrade.

gatekeeper# ip
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
ip [ -force ] -batch filename
where OBJECT := { link | address | addrlabel | route | rule | neigh |
ntable |
tunnel | tuntap | maddress | mroute | mrule |
monitor | xfrm |
netns | l2tp | fou | macsec | tcp_metrics | token |
netconf | ila |
vrf | sr | nexthop | mptcp }
OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
-h[uman-readable] | -iec | -j[son] | -p[retty] |
-f[amily] { inet | inet6 | mpls | bridge | link } |
-4 | -6 | -I | -D | -M | -B | -0 |
-l[oops] { maximum-addr-flush-attempts } | -br[ief] |
-o[neline] | -t[imestamp] | -ts[hort] | -b[atch]
[filename] |
-rc[vbuf] [size] | -n[etns] name | -N[umeric] |
-a[ll] |
-c[olor]}
gatekeeper# bridge --help
-sh: bridge: not found
gatekeeper# ip bridge --help
Object "bridge" is unknown, try "ip help".
gatekeeper# ip bridge show
Object "bridge" is unknown, try "ip help".

cheers

ET

--
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

[david M brooke]

Hi ET,

Now I would argue that we should leave the name convention for the bridge package as is, e.g. bridge.lrp

I agree that would be the 'cleanest' option - provided we can maintain the same behaviour for bridges defined in /etc/network/interfaces (especially since the package name is 'bridge.lrp' and so matches the new command name).

Looking at my currently running box (7.1.0) ip appears not to have this
capability
gatekeeper# bridge --help
-sh: bridge: not found

That is to be expected; we currently only build a small portion of the available iproute2 source functionality, so adding 'bridge' requires a change to the buildtool configuration for the iproute2 source package.

I came across this issue while looking at adding a bridge to my installation, so I am able to do some experiments without breaking anything important. I will see if I can get something working by extending the build environment to compile the 'bridge' executable.

Regards,
dMb