Activity log for bug #1732032

Date Who What changed Old value New value Message
2017-11-13 22:29:17 bugproxy bug added bug
2017-11-13 22:29:22 bugproxy tags architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin---
2017-11-13 22:29:23 bugproxy ubuntu: assignee Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
2017-11-13 22:29:25 bugproxy affects ubuntu iproute2 (Ubuntu)
2017-11-14 05:59:05 Frank Heimes bug task added ubuntu-power-systems
2017-11-14 06:09:43 Frank Heimes ubuntu-power-systems: assignee Canonical Server Team (canonical-server)
2017-11-14 06:09:52 Frank Heimes ubuntu-power-systems: importance Undecided Medium
2017-11-14 06:10:14 Frank Heimes tags architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g
2017-11-20 14:38:22 Andrew Cloke ubuntu-power-systems: assignee Canonical Server Team (canonical-server) David Britton (davidpbritton)
2017-11-20 14:38:27 Manoj Iyer iproute2 (Ubuntu): assignee Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) David Britton (davidpbritton)
2017-11-28 18:04:36 Andrew Cloke ubuntu-power-systems: status New Triaged
2017-11-28 18:05:09 Manoj Iyer ubuntu-power-systems: assignee David Britton (davidpbritton) Canonical Server Team (canonical-server)
2017-11-28 18:15:10 David Britton iproute2 (Ubuntu): assignee David Britton (davidpbritton) Andreas Hasenack (ahasenack)
2017-11-28 22:37:55 Andreas Hasenack iproute2 (Ubuntu): status New In Progress
2017-11-28 22:39:24 Andreas Hasenack bug added subscriber Andreas Hasenack
2017-11-29 20:09:01 Andreas Hasenack 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 <pvorel@suse.cz> 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 <pvorel@suse.cz> 2) https://www.spinics.net/lists/netdev/msg461479.html commit 21503ed2af233ffe795926f6641ac84ec1b15bf9 Author: Michal Kubecek <mkubecek@suse.cz> 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 <mkubecek@suse.cz> Acked-by: Phil Sutter <phil@nwl.cc> Acked-by: Petr Vorel <pvorel@suse.cz> 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 [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [Test Case] * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. [Regression Potential] * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance --- 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 <pvorel@suse.cz> 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 <pvorel@suse.cz> 2) https://www.spinics.net/lists/netdev/msg461479.html commit 21503ed2af233ffe795926f6641ac84ec1b15bf9 Author: Michal Kubecek <mkubecek@suse.cz> 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 <mkubecek@suse.cz>     Acked-by: Phil Sutter <phil@nwl.cc>     Acked-by: Petr Vorel <pvorel@suse.cz> 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
2017-11-29 20:09:18 Andreas Hasenack nominated for series Ubuntu Artful
2017-11-29 20:09:18 Andreas Hasenack nominated for series Ubuntu Xenial
2017-11-29 20:09:18 Andreas Hasenack nominated for series Ubuntu Trusty
2017-11-29 20:09:18 Andreas Hasenack nominated for series Ubuntu Zesty
2017-11-29 20:09:58 Seth Arnold bug task added iproute2 (Ubuntu Artful)
2017-11-29 20:10:05 Seth Arnold bug task added iproute2 (Ubuntu Trusty)
2017-11-29 20:10:12 Seth Arnold bug task added iproute2 (Ubuntu Xenial)
2017-11-29 20:10:24 Seth Arnold bug task added iproute2 (Ubuntu Zesty)
2017-11-29 20:29:16 Andreas Hasenack description [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [Test Case] * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. [Regression Potential] * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance --- 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 <pvorel@suse.cz> 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 <pvorel@suse.cz> 2) https://www.spinics.net/lists/netdev/msg461479.html commit 21503ed2af233ffe795926f6641ac84ec1b15bf9 Author: Michal Kubecek <mkubecek@suse.cz> 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 <mkubecek@suse.cz>     Acked-by: Phil Sutter <phil@nwl.cc>     Acked-by: Petr Vorel <pvorel@suse.cz> 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 [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 <pvorel@suse.cz> 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 <pvorel@suse.cz> 2) https://www.spinics.net/lists/netdev/msg461479.html commit 21503ed2af233ffe795926f6641ac84ec1b15bf9 Author: Michal Kubecek <mkubecek@suse.cz> 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 <mkubecek@suse.cz>     Acked-by: Phil Sutter <phil@nwl.cc>     Acked-by: Petr Vorel <pvorel@suse.cz> 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
2017-11-29 20:38:15 Launchpad Janitor merge proposal linked https://code.launchpad.net/~ahasenack/ubuntu/+source/iproute2/+git/iproute2/+merge/334476
2017-11-29 21:51:14 Launchpad Janitor merge proposal linked https://code.launchpad.net/~ahasenack/ubuntu/+source/iproute2/+git/iproute2/+merge/334482
2017-11-29 21:53:26 Launchpad Janitor merge proposal linked https://code.launchpad.net/~ahasenack/ubuntu/+source/iproute2/+git/iproute2/+merge/334484
2017-11-29 21:55:37 Launchpad Janitor merge proposal linked https://code.launchpad.net/~ahasenack/ubuntu/+source/iproute2/+git/iproute2/+merge/334485
2017-11-29 21:57:07 Launchpad Janitor merge proposal linked https://code.launchpad.net/~ahasenack/ubuntu/+source/iproute2/+git/iproute2/+merge/334486
2017-12-04 13:08:50 Launchpad Janitor iproute2 (Ubuntu): status In Progress Fix Released
2017-12-04 14:44:18 Andrew Cloke ubuntu-power-systems: status Triaged In Progress
2017-12-04 15:35:50 Andreas Hasenack iproute2 (Ubuntu Trusty): status New In Progress
2017-12-04 15:35:53 Andreas Hasenack iproute2 (Ubuntu Xenial): status New In Progress
2017-12-04 15:35:55 Andreas Hasenack iproute2 (Ubuntu Zesty): status New In Progress
2017-12-04 15:35:59 Andreas Hasenack iproute2 (Ubuntu Artful): status New In Progress
2017-12-04 15:36:06 Andreas Hasenack iproute2 (Ubuntu): importance Undecided Medium
2017-12-04 15:36:09 Andreas Hasenack iproute2 (Ubuntu Trusty): importance Undecided Medium
2017-12-04 15:36:15 Andreas Hasenack iproute2 (Ubuntu Zesty): importance Undecided Medium
2017-12-04 15:36:17 Andreas Hasenack iproute2 (Ubuntu Artful): importance Undecided Medium
2017-12-04 15:36:21 Andreas Hasenack iproute2 (Ubuntu Xenial): importance Undecided Medium
2017-12-04 15:36:24 Andreas Hasenack iproute2 (Ubuntu Trusty): assignee Andreas Hasenack (ahasenack)
2017-12-04 15:36:26 Andreas Hasenack iproute2 (Ubuntu Xenial): assignee Andreas Hasenack (ahasenack)
2017-12-04 15:36:28 Andreas Hasenack iproute2 (Ubuntu Zesty): assignee Andreas Hasenack (ahasenack)
2017-12-04 15:36:30 Andreas Hasenack iproute2 (Ubuntu Artful): assignee Andreas Hasenack (ahasenack)
2017-12-06 23:55:09 Robie Basak iproute2 (Ubuntu Trusty): status In Progress Fix Committed
2017-12-06 23:55:11 Robie Basak bug added subscriber Ubuntu Stable Release Updates Team
2017-12-06 23:55:12 Robie Basak bug added subscriber SRU Verification
2017-12-06 23:55:15 Robie Basak tags architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-needed verification-needed-trusty
2017-12-06 23:55:38 Robie Basak iproute2 (Ubuntu Xenial): status In Progress Fix Committed
2017-12-06 23:55:41 Robie Basak tags architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-needed verification-needed-trusty architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-needed verification-needed-trusty verification-needed-xenial
2017-12-06 23:56:01 Robie Basak iproute2 (Ubuntu Zesty): status In Progress Fix Committed
2017-12-06 23:56:05 Robie Basak tags architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-needed verification-needed-trusty verification-needed-xenial architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-needed verification-needed-trusty verification-needed-xenial verification-needed-zesty
2017-12-06 23:56:30 Robie Basak iproute2 (Ubuntu Artful): status In Progress Fix Committed
2017-12-06 23:56:34 Robie Basak tags architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-needed verification-needed-trusty verification-needed-xenial verification-needed-zesty architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-needed verification-needed-artful verification-needed-trusty verification-needed-xenial verification-needed-zesty
2017-12-07 22:19:41 bugproxy tags architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-needed verification-needed-artful verification-needed-trusty verification-needed-xenial verification-needed-zesty architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-done-xenial verification-needed verification-needed-artful verification-needed-trusty verification-needed-zesty
2017-12-07 22:29:35 bugproxy tags architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-done-xenial verification-needed verification-needed-artful verification-needed-trusty verification-needed-zesty architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-done-artful verification-done-xenial verification-needed verification-needed-trusty verification-needed-zesty
2017-12-08 16:40:15 bugproxy tags architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-done-artful verification-done-xenial verification-needed verification-needed-trusty verification-needed-zesty architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-done-artful verification-done-xenial verification-done-zesty verification-needed verification-needed-trusty
2017-12-08 18:59:44 bugproxy tags architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin--- triage-g verification-done-artful verification-done-xenial verification-done-zesty verification-needed verification-needed-trusty architecture-ppc64le bugnameltc-153025 severity-medium targetmilestone-inin1704 triage-g verification-done verification-done-artful verification-done-trusty verification-done-xenial verification-done-zesty
2017-12-11 15:29:57 Frank Heimes ubuntu-power-systems: status In Progress Fix Committed
2018-01-17 11:48:25 Launchpad Janitor iproute2 (Ubuntu Trusty): status Fix Committed Fix Released
2018-01-17 11:48:29 Robie Basak removed subscriber Ubuntu Stable Release Updates Team
2018-01-17 11:48:46 Robie Basak iproute2 (Ubuntu Zesty): status Fix Committed Won't Fix
2018-01-17 11:49:16 Launchpad Janitor iproute2 (Ubuntu Xenial): status Fix Committed Fix Released
2018-01-17 11:49:51 Launchpad Janitor iproute2 (Ubuntu Artful): status Fix Committed Fix Released
2018-03-05 15:19:01 Andrew Cloke ubuntu-power-systems: status Fix Committed Fix Released