Ubuntu
iproute2 package

ip maddr show and ip maddr show dev enP20p96s0 show different data

Bug #1732032 reported by bugproxy on 2017-11-13

This bug affects 1 person

	Status	Importance	Assigned to
The Ubuntu-power-systems project	Fix Released	Medium	Canonical Server
iproute2 (Ubuntu)	Fix Released	Medium	Andreas Hasenack
Trusty	Fix Released	Medium	Andreas Hasenack
Xenial	Fix Released	Medium	Andreas Hasenack
Zesty	Won't Fix	Medium	Andreas Hasenack
Artful	Fix Released	Medium	Andreas Hasenack

Bug Description

[Impact]
When a nic has a long enough name such that there is no space between the name and the ":" in /proc/net/igmp, ip maddr show dev <nic> will miss the IPV4 addresses which is otherwise shown with "ip maddr show".

This is inconsistent behavior and can break scripts and tests, as shown in this bug's original description.

Three patches from upstream were taken to fix this bug, and they were used individually instead of being merged into one single patch so it's easier to track and recognize authorship:
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=530903dd9003492edb0714e937ad4a5d1219e376
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=b48a1161f5f9b6a0cda399a224bbbf72eba4a5c6
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=21503ed2af233ffe795926f6641ac84ec1b15bf9

[Test Case]
* deploy the ubuntu release under test. Please use bare metal or a VM instead of containers, because the ip tool parses a file in /proc. Make sure iproute2 is installed:
sudo apt install iproute2

* Run these commands to setup a dummy interface with a long name and an IPv4 address. Please change the address if it conflicts with a real network you might have available on that machine:

sudo ip link add dummylongnic0 type dummy
sudo ip addr add 192.168.199.10/24 dev dummylongnic0
sudo ip link set dev dummylongnic0 up

* Compare the output of these two commands with regards to the dummylongnic0 interface:
sudo ip maddr show
sudo ip maddr show dev dummylongnic0

* With the buggy iproute2 package installed, the more specific output "ip maddr show dev dummylongnic0" should lack the "inet 224.0.0.1" line:
ip maddr show dev dummylongnic0
2: dummylongnic0
link 33:33:00:00:00:01
link 01:00:5e:00:00:01
inet6 ff02::1
inet6 ff01::1

Whereas the less specific command, which lists all interfaces, will have it listed for dummylongnic0:
2: dummylongnic0
link 33:33:00:00:00:01
link 01:00:5e:00:00:01
inet 224.0.0.1
inet6 ff02::1
inet6 ff01::1

* With the fixed iproute2 package, all dummylongnic0 addresses will be present in both outputs.

[Regression Potential]
In the end, the ip tool is parsing a text file produced by the kernel. As most parsing done in C, it's pretty low level and sensitive to changes in the file it's reading.

[Other Info]
I suggest to conduct the tests in VMs instead of containers (LXD) because the ip maddr command parses /proc/net/igmp, which is produced by the kernel. If you use a container, then it's the host's kernel that will be providing that file and it might not be the same as with the native kernel of that particular ubuntu release.

--- Original description ---
Attn. Canonical: Please make sure that the existing iproute2 package gets updated with the two referenced patches as the missing information is impacting our standard test suites.

Thanks.

== Comment: #0 - Alton L. Pundt - 2017-03-29 14:37:57 ==
---Problem Description---
ip maddr show and ip maddr show dev enP20p96s0 show different data

---uname output---
Linux roselp1 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 15:19:05 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

Machine Type = 8286-42A

---Steps to Reproduce---
run these at command line:
root@roselp1:~# ip maddr show
...
10: enP20p96s0
        link 33:33:00:00:00:01
        link 01:00:5e:00:00:01
        link 33:33:ff:6d:d0:d0
        link 01:00:5e:00:00:fc
        link 33:33:00:01:00:03
        inet 224.0.0.252
        inet 224.0.0.1
        inet6 ff02::1:3
        inet6 ff02::1:ff6d:d0d0 users 3
        inet6 ff02::1
        inet6 ff01::1
...

root@roselp1:~# ip maddr show dev enP20p96s0
10: enP20p96s0
        link 33:33:00:00:00:01
        link 01:00:5e:00:00:01
        link 33:33:ff:6d:d0:d0
        link 01:00:5e:00:00:fc
        link 33:33:00:01:00:03
        inet6 ff02::1:3
        inet6 ff02::1:ff6d:d0d0 users 3
        inet6 ff02::1
        inet6 ff01::1

== Comment: #12 - David Z. Dai - 2017-11-13 15:07:32 ==

I found upstream already had patches that fix this problem:

1) https://www.spinics.net/lists/netdev/msg415009.html
commit 530903dd9003492edb0714e937ad4a5d1219e376
Author: Petr Vorel <email address hidden>
Date: Tue Jan 17 00:25:50 2017 +0100

ip: fix igmp parsing when iface is long

    Entries with long vhost names in /proc/net/igmp have no whitespace
    between name and colon, so sscanf() adds it to vhost and
    'ip maddr show iface' doesn't include inet result.

Signed-off-by: Petr Vorel <email address hidden>

2) https://www.spinics.net/lists/netdev/msg461479.html
commit 21503ed2af233ffe795926f6641ac84ec1b15bf9
Author: Michal Kubecek <email address hidden>
Date: Thu Oct 19 10:21:08 2017 +0200

ip maddr: fix filtering by device

    Commit 530903dd9003 ("ip: fix igmp parsing when iface is long") uses
    variable len to keep trailing colon from interface name comparison. This
    variable is local to loop body but we set it in one pass and use it in
    following one(s) so that we are actually using (pseudo)random length for
    comparison. This became apparent since commit b48a1161f5f9 ("ipmaddr: Avoid
    accessing uninitialized data") always initializes len to zero so that the
    name comparison is always true. As a result, "ip maddr show dev eth0" shows
    IPv4 multicast addresses for all interfaces.

Instead of keeping the length, let's simply replace the trailing colon with
a null byte. The bonus is that we get correct interface name in ma.name.

    Fixes: 530903dd9003 ("ip: fix igmp parsing when iface is long")
    Signed-off-by: Michal Kubecek <email address hidden>
    Acked-by: Phil Sutter <email address hidden>
    Acked-by: Petr Vorel <email address hidden>

The fix is in the same place, but different way.
This is the current implementation In ip/ipmaddr.c file:
struct ma_info *ma;

if (buf[0] != '\t') {
size_t len;

                        sscanf(buf, "%d%s", &m.index, m.name);
                        len = strlen(m.name);
                        if (m.name[len - 1] == ':')
                                m.name[len - 1] = '\0';
                        continue;
                }

The existing "ip" command that shows the problem:
[root@coral-sriov-host1 ip]# /usr/sbin/ip maddr show dev enP1p12s0f0 /* <-- We do NOT see the IPv4 maddr */
2: enP1p12s0f0
        link 01:00:5e:00:00:01
        inet6 ff02::1
        inet6 ff01::1

I clone the latest "ip" utility from upstream to the same test box.
[root@coral-sriov-host1 git_iproute2]# git clone https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git

I build the "ip" utility on same test box, which has the above 2 patches included.

[root@coral-sriov-host1 ip]# /root/git_iproute2/iproute2/ip/ip maddr show dev enP1p12s0f0 /* <--- shows correct IPv4 maddr */
2: enP1p12s0f0
        link 01:00:5e:00:00:01
        inet 224.0.0.1 /* <--- */
        inet6 ff02::1
        inet6 ff01::1

See original description

Tags:

bugproxy (bugproxy) on 2017-11-13

tags:	added: architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin---
Changed in ubuntu:
assignee:	nobody → Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
affects:	ubuntu → iproute2 (Ubuntu)

Frank Heimes (fheimes) on 2017-11-14

Changed in ubuntu-power-systems:
assignee:	nobody → Canonical Server Team (canonical-server)
importance:	Undecided → Medium
tags:	added: triage-g

Andrew Cloke (andrew-cloke) on 2017-11-20

Changed in ubuntu-power-systems:
assignee:	Canonical Server Team (canonical-server) → David Britton (davidpbritton)

Manoj Iyer (manjo) on 2017-11-20

Changed in iproute2 (Ubuntu):
assignee:	Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) → David Britton (davidpbritton)

Andrew Cloke (andrew-cloke) on 2017-11-28

Changed in ubuntu-power-systems:
status:	New → Triaged

Manoj Iyer (manjo) on 2017-11-28

Changed in ubuntu-power-systems:
assignee:	David Britton (davidpbritton) → Canonical Server Team (canonical-server)

David Britton (dpb) on 2017-11-28

Changed in iproute2 (Ubuntu):
assignee:	David Britton (davidpbritton) → Andreas Hasenack (ahasenack)

Andreas Hasenack (ahasenack) on 2017-11-28

Changed in iproute2 (Ubuntu):
status:	New → In Progress

Revision history for this message

Andreas Hasenack (ahasenack) wrote on 2017-11-29:

We also need to fix the FTBFS problem in order to proceed with an SRU: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1735158

Revision history for this message

Andreas Hasenack (ahasenack) wrote on 2017-11-29:

commit ae717baf15fb4d30749ada3948d9445892bac239
Author: Khem Raj <email address hidden>
Date: Sat May 20 14:28:46 2017 -0700

tc: include stdint.h explicitly for UINT16_MAX

    Fixes
    | tc_core.c:190:29: error: 'UINT16_MAX' undeclared (first use in this function); did you mean '__INT16_MAX__'?
    | if ((sz >> s->size_log) > UINT16_MAX) {
    | ^~~~~~~~~~

Signed-off-by: Khem Raj <email address hidden>

Andreas Hasenack (ahasenack) on 2017-11-29

description:

updated

Andreas Hasenack (ahasenack) on 2017-11-29

description:

updated

Revision history for this message

Launchpad Janitor (janitor) wrote on 2017-12-04:

This bug was fixed in the package iproute2 - 4.9.0-1ubuntu3

---------------
iproute2 (4.9.0-1ubuntu3) bionic; urgency=medium

  * Fix ip maddr show (LP: #1732032):
    - d/p/1003-ip-maddr-fix-igmp-parsing.patch: fix igmp parsing when iface is
      long
    - d/p/1004-ip-maddr-avoid-uninitialized-data.patch: avoid accessing
      uninitialized data
    - d/p/1005-ip-maddr-fix-filtering-by-device.patch: fix filtering
      by device
  * d/p/1006-fix-undeclared-UINT16_MAX.patch: FTBFS: tc: include stdint.h
    explicitly for UINT16_MAX (LP: #1735158)

-- Andreas Hasenack <email address hidden> Wed, 29 Nov 2017 09:35:46 -0200

Changed in iproute2 (Ubuntu):
status:	In Progress → Fix Released

Andrew Cloke (andrew-cloke) on 2017-12-04

Changed in ubuntu-power-systems:
status:	Triaged → In Progress

Andreas Hasenack (ahasenack) on 2017-12-04

Changed in iproute2 (Ubuntu Trusty):
status:	New → In Progress
Changed in iproute2 (Ubuntu Xenial):
status:	New → In Progress
Changed in iproute2 (Ubuntu Zesty):
status:	New → In Progress
Changed in iproute2 (Ubuntu Artful):
status:	New → In Progress
Changed in iproute2 (Ubuntu):
importance:	Undecided → Medium
Changed in iproute2 (Ubuntu Trusty):
importance:	Undecided → Medium
Changed in iproute2 (Ubuntu Zesty):
importance:	Undecided → Medium
Changed in iproute2 (Ubuntu Artful):
importance:	Undecided → Medium
Changed in iproute2 (Ubuntu Xenial):
importance:	Undecided → Medium
Changed in iproute2 (Ubuntu Trusty):
assignee:	nobody → Andreas Hasenack (ahasenack)
Changed in iproute2 (Ubuntu Xenial):
assignee:	nobody → Andreas Hasenack (ahasenack)
Changed in iproute2 (Ubuntu Zesty):
assignee:	nobody → Andreas Hasenack (ahasenack)
Changed in iproute2 (Ubuntu Artful):
assignee:	nobody → Andreas Hasenack (ahasenack)

Revision history for this message

Robie Basak (racb) wrote on 2017-12-06: Please test proposed package

Hello bugproxy, or anyone else affected,

Accepted iproute2 into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/iproute2/3.12.0-2ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in iproute2 (Ubuntu Trusty):
status:	In Progress → Fix Committed
tags:	added: verification-needed verification-needed-trusty
Changed in iproute2 (Ubuntu Xenial):
status:	In Progress → Fix Committed
tags:	added: verification-needed-xenial

Revision history for this message

Robie Basak (racb) wrote on 2017-12-06:

Hello bugproxy, or anyone else affected,

Accepted iproute2 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/iproute2/4.3.0-1ubuntu3.16.04.3 in a few hours, and then in the -proposed repository.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in iproute2 (Ubuntu Zesty):
status:	In Progress → Fix Committed
tags:	added: verification-needed-zesty

Revision history for this message

Robie Basak (racb) wrote on 2017-12-06:

Hello bugproxy, or anyone else affected,

Accepted iproute2 into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/iproute2/4.9.0-1ubuntu1.1 in a few hours, and then in the -proposed repository.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in iproute2 (Ubuntu Artful):
status:	In Progress → Fix Committed
tags:	added: verification-needed-artful

Revision history for this message

Robie Basak (racb) wrote on 2017-12-06:

Hello bugproxy, or anyone else affected,

Accepted iproute2 into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/iproute2/4.9.0-1ubuntu2.1 in a few hours, and then in the -proposed repository.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Revision history for this message

bugproxy (bugproxy) wrote on 2017-12-07: Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2017-12-07 17:15 EDT-------
Validated 4.3.0-1ubuntu3.16.04.3 for xenial.

tags:

added: verification-done-xenial
removed: verification-needed-xenial

Revision history for this message

bugproxy (bugproxy) wrote on 2017-12-07:

------- Comment From <email address hidden> 2017-12-07 17:19 EDT-------
Validated 4.9.0-1ubuntu2.1 for artful:

root@artful:~# ip maddr show reallylongname
5: reallylongname
link 33:33:00:00:00:01
link 01:00:5e:00:00:01
link 33:33:ff:0c:0c:27
link 33:33:00:01:00:03
inet 224.0.0.1
inet6 ff02::1:3
inet6 ff02::1:ff0c:c27
inet6 ff02::1
inet6 ff01::1

tags:

added: verification-done-artful
removed: verification-needed-artful

Revision history for this message

bugproxy (bugproxy) wrote on 2017-12-08:

#10

------- Comment From <email address hidden> 2017-12-08 11:38 EDT-------
Validated 4.9.0-1ubuntu1.1 for zesty

tags:

added: verification-done-zesty
removed: verification-needed-zesty

Revision history for this message

bugproxy (bugproxy) wrote on 2017-12-08:

#11

------- Comment From <email address hidden> 2017-12-08 13:55 EDT-------
Verified 3.12.0-2ubuntu1.2 for trusty

tags:

added: targetmilestone-inin1704 verification-done verification-done-trusty
removed: targetmilestone-inin--- verification-needed verification-needed-trusty

Frank Heimes (fheimes) on 2017-12-11

Changed in ubuntu-power-systems:
status:	In Progress → Fix Committed

Revision history for this message

Robie Basak (racb) wrote on 2017-12-20:

#12

Could someone look at the autopkgtest failures listed against iproute2 in http://people.canonical.com/~ubuntu-archive/pending-sru.html please? IIRC, firejail on s390x is a false positive? But there are some others, too.

Also, has anyone done a quite smoke on amd64 to make sure the "ip" command still works there? If not, could you please do that? It's quite a core package and I don't want to find out that regressed the world by pressing the button to release this without checking this. Sorry, I should have asked for that at review/accept time.

Revision history for this message

Andreas Hasenack (ahasenack) wrote on 2017-12-26:

#13

I had a super nice and detailed reply written here, but of course I lost it. Browsers are stupid things sometimes. So here are the comments that survived.

TL;DR:
firejail is known to fail on s390 because there is no thunderbird package for a mainframe. I emailed ubuntu-devel@ and also pinged #ubuntu-devel on irc. Switching the test bed from a container to a VM for s390 a while back allowed this new test to run.

Others are green, with the exception of trusty:
a) armhf: fails copying the device /dev/null elsewhere with -a, which equates to creating a device outside of tmp, which is forbidden. Last time this worked was when the test bed was on lxc in 2016. On lxd it doesn't work. The other architectures are not using lxd. We should probably add a constraint so that the test only runs in vms. Should it be added to the current SRU package for trusty?

b) ppc: a grub error:
Generating grub configuration file ...
grub-probe: error: not a directory.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1

I pinged #ubuntu-devel about it, since I have no idea how to setup and run a ppc vm, but got no response:

https://irclogs.ubuntu.com/2017/12/07/%23ubuntu-devel.html#t19:33

ahasenack is there something going on with setting up ppc64el autopkg tests in excuses? I have 3 different packages failing there with the same error 19:33
ahasenack grub-probe: error: not a directory. 19:33
ahasenack run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1 19:33
ahasenack in trusty 19:33
ahasenack https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/ppc64el/a/autopkgtest/20171207_002904_c5112@/log.gz is one of them

Got no response. I don't even know if grub is used in ppc.

Regarding amd64 smoke test, I've been using the updated package on my machine (artful/amd64).

Revision history for this message

Robie Basak (racb) wrote on 2018-01-03:

#14

Thanks. That all looks fine then.

> Regarding amd64 smoke test, I've been using the updated package on my machine (artful/amd64).

Does that actually exercise the ip command though? Or are you using Network Manager, and does it speak to the kernel directly?

Revision history for this message

Andreas Hasenack (ahasenack) wrote on 2018-01-04:

#15

Well, network-manager depends on iproute2, as do many other things. When I try to remove iproute2 from my system I get this:

The following packages will be REMOVED:
gnome-control-center* ifupdown* iproute2* isc-dhcp-client* keepalived* network-manager* network-manager-config-connectivity-ubuntu* network-manager-gnome* network-manager-openvpn*
network-manager-openvpn-gnome* network-manager-pptp* network-manager-pptp-gnome* openvpn* pppoeconf* ubuntu-desktop*

Of these I use extensively openvpn (via network manager) and, although it's not listed as a dependency, lxd (in the host), which I just confirmed uses iproute2 to set up its bridges and networking.

That being said, this is on artful, not xenial. The xenial dep8 tests in the excuses page are all green, though.

I'll setup up a xenial vm, with a lot of networking "things" (nics, bridges, server software), update iproute2, and let it boot.

Revision history for this message

Andreas Hasenack (ahasenack) wrote on 2018-01-04:

#16

I installed the updated package on an existing maas server on xenial/amd64, and deployed a new node (also xenial/amd64) where I also installed the updated package plus some server software. No visible side effects.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2018-01-17:

#17

This bug was fixed in the package iproute2 - 3.12.0-2ubuntu1.2

---------------
iproute2 (3.12.0-2ubuntu1.2) trusty; urgency=medium

-- Andreas Hasenack <email address hidden> Wed, 29 Nov 2017 17:15:25 -0200

Changed in iproute2 (Ubuntu Trusty):
status:	Fix Committed → Fix Released

Revision history for this message

Robie Basak (racb) wrote on 2018-01-17: Update Released

#18

The verification of the Stable Release Update for iproute2 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Changed in iproute2 (Ubuntu Zesty):
status:	Fix Committed → Won't Fix

Revision history for this message

Launchpad Janitor (janitor) wrote on 2018-01-17:

#19

This bug was fixed in the package iproute2 - 4.3.0-1ubuntu3.16.04.3

---------------
iproute2 (4.3.0-1ubuntu3.16.04.3) xenial; urgency=medium

  * Fix ip maddr show (LP: #1732032):
    - d/p/1005-ip-maddr-fix-igmp-parsing.patch: fix igmp parsing when iface is
      long
    - d/p/1006-ip-maddr-avoid-uninitialized-data.patch: avoid accessing
      uninitialized data
    - d/p/1007-ip-maddr-fix-filtering-by-device.patch: fix filtering
      by device

-- Andreas Hasenack <email address hidden> Wed, 29 Nov 2017 15:04:40 -0200

Changed in iproute2 (Ubuntu Xenial):
status:	Fix Committed → Fix Released

Revision history for this message

Launchpad Janitor (janitor) wrote on 2018-01-17:

#20

This bug was fixed in the package iproute2 - 4.9.0-1ubuntu2.1

---------------
iproute2 (4.9.0-1ubuntu2.1) artful; urgency=medium

-- Andreas Hasenack <email address hidden> Wed, 29 Nov 2017 11:02:27 -0200

Changed in iproute2 (Ubuntu Artful):
status:	Fix Committed → Fix Released

Andrew Cloke (andrew-cloke) on 2018-03-05

Changed in ubuntu-power-systems:
status:	Fix Committed → Fix Released

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.

Ubuntuiproute2 package

ip maddr show and ip maddr show dev enP20p96s0 show different data

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
iproute2 package