2017-04-14 16:32:43 |
Scott Moser |
bug |
|
|
added bug |
2017-04-14 16:37:10 |
Scott Moser |
cloud-init: status |
New |
Confirmed |
|
2017-04-14 16:37:12 |
Scott Moser |
cloud-init: importance |
Undecided |
Medium |
|
2017-04-14 16:51:08 |
Scott Moser |
attachment added |
|
btest-launch.sh https://bugs.launchpad.net/cloud-init/+bug/1682871/+attachment/4862136/+files/btest-launch.sh |
|
2017-04-14 17:00:51 |
Scott Moser |
summary |
attempts to rename vlans / get_interfaces_by_mac does not filter vlans |
attempts to rename vlans / vlans have addr_assign_type of 2 |
|
2017-04-14 17:01:01 |
Scott Moser |
summary |
attempts to rename vlans / vlans have addr_assign_type of 2 |
attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4 |
|
2017-04-14 17:01:49 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu) |
|
2017-04-14 17:02:03 |
Scott Moser |
cloud-init (Ubuntu): status |
New |
Confirmed |
|
2017-04-14 17:02:25 |
Scott Moser |
bug task added |
|
linux (Ubuntu) |
|
2017-04-14 17:02:41 |
Scott Moser |
linux (Ubuntu): status |
New |
Fix Released |
|
2017-04-14 17:02:51 |
Scott Moser |
nominated for series |
|
Ubuntu Xenial |
|
2017-04-14 17:02:51 |
Scott Moser |
bug task added |
|
linux (Ubuntu Xenial) |
|
2017-04-14 17:02:51 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Xenial) |
|
2017-04-14 17:05:10 |
Scott Moser |
description |
When attempting to verify sru for bug 1669860, I found that vlans
are not properly filtered out by 'get_interfaces_by_mac'. That means
that the bug is still present with vlans.
Related bugs:
* bug 1669860: cloud-init attempts to rename bonds |
When attempting to verify sru for bug 1669860, I found that vlans
are not properly filtered out by 'get_interfaces_by_mac'. That means
that the bug is still present with vlans.
The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type
shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8.
See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
for doc on addr_assign_type.
Related bugs:
* bug 1669860: cloud-init attempts to rename bonds |
|
2017-04-14 17:05:14 |
Scott Moser |
linux (Ubuntu Xenial): status |
New |
Confirmed |
|
2017-04-14 17:05:26 |
Scott Moser |
cloud-init (Ubuntu Xenial): status |
New |
Confirmed |
|
2017-04-14 17:05:34 |
Scott Moser |
cloud-init (Ubuntu Xenial): importance |
Undecided |
Medium |
|
2017-04-14 17:05:39 |
Scott Moser |
cloud-init (Ubuntu): importance |
Undecided |
Medium |
|
2017-04-19 15:57:56 |
Dimitri John Ledkov |
description |
When attempting to verify sru for bug 1669860, I found that vlans
are not properly filtered out by 'get_interfaces_by_mac'. That means
that the bug is still present with vlans.
The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type
shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8.
See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
for doc on addr_assign_type.
Related bugs:
* bug 1669860: cloud-init attempts to rename bonds |
[Impact]
* When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen.
* When underlying interface MAC address is changed, it does not propagate to the vlan interfaces.
[Test Case]
* Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0.
* Update the base interface mac address, the mac address of the vlan interface should change too.
[Regression Potential]
* Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.6+ kernels.
[Other Info]
* Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels
commit 308453aa9156a3b8ee382c0949befb507a32b0c1
Author: Mike Manning <mmanning@brocade.com>
Date: Fri May 27 17:45:07 2016 +0100
vlan: Propagate MAC address to VLANs
The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.
The VLANs should continue inheriting the MAC address of the physical
interface until the VLAN MAC address is explicitly set to any value.
This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
to the MAC of the physical interface and thus for DAD to behave as
expected.
Signed-off-by: Mike Manning <mmanning@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* Original bug report
When attempting to verify sru for bug 1669860, I found that vlans
are not properly filtered out by 'get_interfaces_by_mac'. That means
that the bug is still present with vlans.
The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type
shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8.
See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
for doc on addr_assign_type.
Related bugs:
* bug 1669860: cloud-init attempts to rename bonds |
|
2017-04-19 15:58:02 |
Dimitri John Ledkov |
linux (Ubuntu Xenial): status |
Confirmed |
Triaged |
|
2017-04-19 15:58:04 |
Dimitri John Ledkov |
linux (Ubuntu Xenial): importance |
Undecided |
High |
|
2017-04-19 15:58:11 |
Dimitri John Ledkov |
linux (Ubuntu Xenial): assignee |
|
Canonical Kernel (canonical-kernel) |
|
2017-04-19 16:00:27 |
Dimitri John Ledkov |
attachment added |
|
0001-vlan-Propagate-MAC-address-to-VLANs.patch https://bugs.launchpad.net/cloud-init/+bug/1682871/+attachment/4864939/+files/0001-vlan-Propagate-MAC-address-to-VLANs.patch |
|
2017-04-19 16:12:46 |
Kleber Sacilotto de Souza |
bug |
|
|
added subscriber Kleber Sacilotto de Souza |
2017-04-19 16:25:30 |
Dimitri John Ledkov |
attachment added |
|
vlans-steal-mac-addresses.patch https://bugs.launchpad.net/cloud-init/+bug/1682871/+attachment/4864966/+files/vlans-steal-mac-addresses.patch |
|
2017-04-19 16:26:05 |
Dimitri John Ledkov |
description |
[Impact]
* When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen.
* When underlying interface MAC address is changed, it does not propagate to the vlan interfaces.
[Test Case]
* Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0.
* Update the base interface mac address, the mac address of the vlan interface should change too.
[Regression Potential]
* Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.6+ kernels.
[Other Info]
* Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels
commit 308453aa9156a3b8ee382c0949befb507a32b0c1
Author: Mike Manning <mmanning@brocade.com>
Date: Fri May 27 17:45:07 2016 +0100
vlan: Propagate MAC address to VLANs
The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.
The VLANs should continue inheriting the MAC address of the physical
interface until the VLAN MAC address is explicitly set to any value.
This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
to the MAC of the physical interface and thus for DAD to behave as
expected.
Signed-off-by: Mike Manning <mmanning@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* Original bug report
When attempting to verify sru for bug 1669860, I found that vlans
are not properly filtered out by 'get_interfaces_by_mac'. That means
that the bug is still present with vlans.
The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type
shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8.
See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
for doc on addr_assign_type.
Related bugs:
* bug 1669860: cloud-init attempts to rename bonds |
[Impact]
* When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen.
* When underlying interface MAC address is changed, it does not propagate to the vlan interfaces.
[Test Case]
* Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0.
* Update the base interface mac address, the mac address of the vlan interface should change too.
[Regression Potential]
* Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.7+ kernels.
[Other Info]
* Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels
commit 308453aa9156a3b8ee382c0949befb507a32b0c1
Author: Mike Manning <mmanning@brocade.com>
Date: Fri May 27 17:45:07 2016 +0100
vlan: Propagate MAC address to VLANs
The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.
The VLANs should continue inheriting the MAC address of the physical
interface until the VLAN MAC address is explicitly set to any value.
This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
to the MAC of the physical interface and thus for DAD to behave as
expected.
Signed-off-by: Mike Manning <mmanning@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* Original bug report
When attempting to verify sru for bug 1669860, I found that vlans
are not properly filtered out by 'get_interfaces_by_mac'. That means
that the bug is still present with vlans.
The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type
shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8.
See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
for doc on addr_assign_type.
Related bugs:
* bug 1669860: cloud-init attempts to rename bonds |
|
2017-04-19 16:28:14 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
2017-04-20 10:12:16 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~xnox/cloud-init/+git/cloud-init/+merge/322828 |
|
2017-04-26 01:30:48 |
Launchpad Janitor |
cloud-init (Ubuntu): status |
Confirmed |
Fix Released |
|
2017-05-03 22:04:33 |
Chad Smith |
description |
[Impact]
* When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen.
* When underlying interface MAC address is changed, it does not propagate to the vlan interfaces.
[Test Case]
* Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0.
* Update the base interface mac address, the mac address of the vlan interface should change too.
[Regression Potential]
* Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.7+ kernels.
[Other Info]
* Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels
commit 308453aa9156a3b8ee382c0949befb507a32b0c1
Author: Mike Manning <mmanning@brocade.com>
Date: Fri May 27 17:45:07 2016 +0100
vlan: Propagate MAC address to VLANs
The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.
The VLANs should continue inheriting the MAC address of the physical
interface until the VLAN MAC address is explicitly set to any value.
This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
to the MAC of the physical interface and thus for DAD to behave as
expected.
Signed-off-by: Mike Manning <mmanning@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* Original bug report
When attempting to verify sru for bug 1669860, I found that vlans
are not properly filtered out by 'get_interfaces_by_mac'. That means
that the bug is still present with vlans.
The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type
shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8.
See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
for doc on addr_assign_type.
Related bugs:
* bug 1669860: cloud-init attempts to rename bonds |
[Impact]
* When vlan interfaces are created, their mac address is copied from the underlying interface, but it is not marked by kernel as stolen.
* When underlying interface MAC address is changed, it does not propagate to the vlan interfaces.
[Test Case]
* Create vlan interface, check the addr_assign_type sysfs attribute, it should be 2, not 0.
* Update the base interface mac address, the mac address of the vlan interface should change too.
* cloud-init test case
wget https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/get-proposed-cloudimg;
chmod 755 get-proposed-cloudimg;
for release in xenial yakkety zesty; do
./get-proposed-cloudimg $release;
MODE=vlan ./btest-launch.sh $release-server-cloudimg-amd64-proposed.img <LP_ID>;
# ubuntu/passw0rd
python3 -c 'from cloudinit.net import get_interfaces_by_mac; print(get_interfaces_by_mac())'; # results in no runtime error and doesn't report vlan interface name
done
[Regression Potential]
* Userspace may rely on non-propagating MAC addresses, and the fact that vlan mac address type is wrongly stated as non-stolen; however this behaviour will be consistent with 4.7+ kernels.
[Other Info]
* Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into v4.4 kernels
commit 308453aa9156a3b8ee382c0949befb507a32b0c1
Author: Mike Manning <mmanning@brocade.com>
Date: Fri May 27 17:45:07 2016 +0100
vlan: Propagate MAC address to VLANs
The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.
The VLANs should continue inheriting the MAC address of the physical
interface until the VLAN MAC address is explicitly set to any value.
This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
to the MAC of the physical interface and thus for DAD to behave as
expected.
Signed-off-by: Mike Manning <mmanning@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* Original bug report
When attempting to verify sru for bug 1669860, I found that vlans
are not properly filtered out by 'get_interfaces_by_mac'. That means
that the bug is still present with vlans.
The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type
shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8.
See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
for doc on addr_assign_type.
Related bugs:
* bug 1669860: cloud-init attempts to rename bonds |
|
2017-05-05 14:01:34 |
Scott Moser |
nominated for series |
|
Ubuntu Yakkety |
|
2017-05-05 14:01:34 |
Scott Moser |
bug task added |
|
linux (Ubuntu Yakkety) |
|
2017-05-05 14:01:34 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Yakkety) |
|
2017-05-05 14:01:34 |
Scott Moser |
nominated for series |
|
Ubuntu Zesty |
|
2017-05-05 14:01:34 |
Scott Moser |
bug task added |
|
linux (Ubuntu Zesty) |
|
2017-05-05 14:01:34 |
Scott Moser |
bug task added |
|
cloud-init (Ubuntu Zesty) |
|
2017-05-05 15:44:55 |
Scott Moser |
cloud-init (Ubuntu Yakkety): status |
New |
Confirmed |
|
2017-05-05 15:44:57 |
Scott Moser |
cloud-init (Ubuntu Zesty): status |
New |
Confirmed |
|
2017-05-05 15:45:00 |
Scott Moser |
cloud-init (Ubuntu Yakkety): importance |
Undecided |
Medium |
|
2017-05-05 15:45:02 |
Scott Moser |
cloud-init (Ubuntu Zesty): importance |
Undecided |
Medium |
|
2017-05-08 19:05:31 |
Steve Langasek |
cloud-init (Ubuntu Xenial): status |
Confirmed |
Fix Committed |
|
2017-05-08 19:05:36 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
2017-05-08 19:05:42 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
2017-05-08 19:05:49 |
Steve Langasek |
tags |
patch |
patch verification-needed |
|
2017-05-11 20:20:57 |
Chad Smith |
tags |
patch verification-needed |
patch verification-done-xenial verification-needed |
|
2017-05-11 20:30:37 |
Steve Langasek |
cloud-init (Ubuntu Yakkety): status |
Confirmed |
Fix Committed |
|
2017-05-11 20:37:30 |
Steve Langasek |
cloud-init (Ubuntu Zesty): status |
Confirmed |
Fix Committed |
|
2017-05-12 13:27:02 |
Kleber Sacilotto de Souza |
linux (Ubuntu Xenial): status |
Triaged |
In Progress |
|
2017-05-12 13:55:43 |
Kleber Sacilotto de Souza |
linux (Ubuntu Yakkety): status |
New |
Fix Released |
|
2017-05-12 13:55:48 |
Kleber Sacilotto de Souza |
linux (Ubuntu Zesty): status |
New |
Fix Released |
|
2017-05-12 19:15:34 |
Chad Smith |
tags |
patch verification-done-xenial verification-needed |
patch verification-done-xenial verification-done-yakkety verification-done-zesty |
|
2017-05-16 13:07:08 |
Kleber Sacilotto de Souza |
linux (Ubuntu Xenial): assignee |
Canonical Kernel (canonical-kernel) |
Kleber Sacilotto de Souza (kleber-souza) |
|
2017-05-17 02:58:17 |
Launchpad Janitor |
cloud-init (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
2017-05-17 02:59:03 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
2017-05-17 03:07:38 |
Launchpad Janitor |
cloud-init (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
2017-05-17 03:14:07 |
Launchpad Janitor |
cloud-init (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
2017-05-19 09:06:56 |
Dimitri John Ledkov |
cloud-init: status |
Confirmed |
Fix Committed |
|
2017-05-31 11:16:41 |
Thadeu Lima de Souza Cascardo |
linux (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
2017-06-28 16:35:34 |
Launchpad Janitor |
linux (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
2017-06-28 16:35:34 |
Launchpad Janitor |
cve linked |
|
2017-1000364 |
|
2017-06-28 16:35:34 |
Launchpad Janitor |
cve linked |
|
2017-8890 |
|
2017-06-28 16:35:34 |
Launchpad Janitor |
cve linked |
|
2017-9074 |
|
2017-06-28 16:35:34 |
Launchpad Janitor |
cve linked |
|
2017-9075 |
|
2017-06-28 16:35:34 |
Launchpad Janitor |
cve linked |
|
2017-9076 |
|
2017-06-28 16:35:34 |
Launchpad Janitor |
cve linked |
|
2017-9077 |
|
2017-06-28 16:35:34 |
Launchpad Janitor |
cve linked |
|
2017-9242 |
|
2017-09-23 02:31:03 |
Scott Moser |
cloud-init: status |
Fix Committed |
Fix Released |
|
2023-05-10 23:47:00 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/2858 |
|