Support IP address protocol

Status changed to 'Confirmed' because the bug affects multiple users.

Thank you! I confirmed that the added distro-patches match the upstream patches. The feature looks useful, but it's not very common to backport new features as part of an SRU... So I'll leave that decision to the SRU team.

In either way, this should probably first be fixed in the current "devel" series, i.e. by merging iproute2 v6.4+ from Debian unstable. Once that is accomplished, we can consider this patch for SRU. Would you be interested in working on that merge?

Nitpick: When aiming for SRU, you should consider updating the SRU template in the bug description to the latest version (although, the one you used might also be accepted as-is) and also change the version number according to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging, e.g.: 6.1.0-1ubuntu2.1

https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

I agree that a merge from debian would be better, since we are quite behind:

iproute2 | 6.5.0-4 | testing

But we have been at 6.1.0 since at least lunar, so I don't know how long that would take. I think we can take these patches for noble.

I would ask that you also add this one, though, to update the manpage with the new option:

commit 1fbb61058d34e3eb9a34f5e930bbbb8d90c4a961
Author: Petr Machata <email address hidden>
Date: Mon Mar 27 18:12:06 2023 +0200

    man: man8: Add man page coverage for "ip address add ... proto"

    Signed-off-by: Petr Machata <email address hidden>
    Signed-off-by: David Ahern <email address hidden>

Also, you could perhaps add your test script as a quick DEP8 test, what do you think? Something like this?

--- a/debian/tests/control
+++ b/debian/tests/control
@@ -3,3 +3,7 @@
 Tests: testsuite.sh
 Restrictions: allow-stderr, isolation-machine, needs-root, rw-build-tree
 Depends: build-essential, locales-all, dpkg-dev, sudo:native, kmod, @builddeps@
+
+Tests: test-protocol-attribute
+Restrictions: isolation-machine, needs-root
+Depends: iproute2
diff --git a/debian/tests/test-protocol-attribute.sh b/debian/tests/test-protocol-attribute.sh
new file mode 100755
index 00000000..254b2906
--- /dev/null
+++ b/debian/tests/test-protocol-attribute.sh
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+addr=192.0.2.1/28
+ifr=test-dummy123
+
+ip link add name "$ifr" type dummy
+ip link set "$ifr" up
+
+ip address add dev "$ifr" "$addr" proto 0x99
+
+ip link del "$ifr"

Perhaps improve it with using a random address, and showing the "ip a" output and checking that "proto 0x99" was truly added.

Finally, it would also be good if the patches have a few more DEP3 headers. In particular, Origin, with a link to the upstream commit, and also a pointer to this bug here (Bug-Ubuntu: ...). The hash in the "From" bit in both patches didn't match the upstreams I could find (git://git.kernel.org/pub/scm/network/iproute2/iproute2.git or https://github.com/shemminger/iproute2.git), but I did find the commits using a log search. It would help if the Origin tag were there, then, with a direct link.

Regarding an SRU, I would have some concerns:

- what is the real user benefit for stable release users? Do we have bugs filed against iproute2 asking for this feature? How much demand is there for this? In which kind of deployment would this be most useful?

- I see that the "ip" output changes when this flag is present, with the new "proto <val>" string. What's the regression potential here for parsing this output in scripts? I believe the new "proto <val>" text is only present if there was a protocol assigned, and if not, the default value (0 I believe?) is not shown. But are there other regression potentials here? Perhaps in the json output, or when some extra flag is added to "ip" commands?