[Yahoo-eng-team] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

[Scott Moser]

This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New

Thank you.

** Changed in: cloud-init
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1682871

Title:
  attempts to rename vlans / vlans have addr_assign_type of 0 on kernel
  4.4

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released
Status in linux source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released

Bug 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.

   * 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 
;
# 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 
  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 
  Signed-off-by: David S. Miller 

   * 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//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

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1682871/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.4.0-83.106

---
linux (4.4.0-83.106) xenial; urgency=low

  * linux: 4.4.0-83.106 -proposed tracker (LP: #1700541)

  * CVE-2017-1000364
- Revert "UBUNTU: SAUCE: mm: Only expand stack if guard area is hit"
- Revert "mm: do not collapse stack gap into THP"
- Revert "mm: enlarge stack guard gap"
- mm: vma_adjust: remove superfluous confusing update in remove_next == 1 
case
- mm: larger stack guard gap, between vmas
- mm: fix new crash in unmapped_area_topdown()
- Allow stack to grow up to address space limit

linux (4.4.0-82.105) xenial; urgency=low

  * linux: 4.4.0-82.105 -proposed tracker (LP: #1699064)

  * CVE-2017-1000364
- SAUCE: mm: Only expand stack if guard area is hit

  * linux-aws/linux-gke incorrectly producing and using linux-*-tools-
common/linux-*-cloud-tools-common (LP: #1688579)
- [Config] make linux-tools-common and linux-cloud-tools-common protection
  consistent

  * CVE-2017-9242
- ipv6: fix out of bound writes in __ip6_append_data()

  * CVE-2017-9075
- sctp: do not inherit ipv6_{mc|ac|fl}_list from parent

  * CVE-2017-9074
- ipv6: Prevent overrun when parsing v6 header options

  * CVE-2017-9076
- ipv6/dccp: do not inherit ipv6_mc_list from parent

  * CVE-2017-9077
- ipv6/dccp: do not inherit ipv6_mc_list from parent

  * CVE-2017-8890
- dccp/tcp: do not inherit mc_list from parent

  * Module signing exclusion for staging drivers does not work properly
(LP: #1690908)
- SAUCE: Fix module signing exclusion in package builds

  * extend-diff-ignore should use exact matches (LP: #1693504)
- [Packaging] exact extend-diff-ignore matches

  * Dell XPS 9360 wifi 5G performance is poor (LP: #1692836)
- SAUCE: ath10k: fix the wifi speed issue for kill 1535

  *  Upgrade Redpine WLAN/BT driver to ver. 1.2.RC12 (LP: #1694607)
- SAUCE: Redpine: Upgrade to ver. 1.2.RC12

  * [DP MST] No audio output through HDMI/DP/mDP ports in Dell WD15 and TB15
docking stations (LP: #1694665)
- drm/i915: Store port enum in intel_encoder
- drm/i915: Eliminate redundant local variable definition
- drm/i915: Switch to using port stored in intel_encoder
- drm/i915: Move audio_connector to intel_encoder
- drm/i915/dp: DP audio API changes for MST
- drm/i915: abstract ddi being audio enabled
- drm/i915/audio: extend get_saved_enc() to support more scenarios
- drm/i915: enable dp mst audio

  * Xenial update to 4.4.70 stable release (LP: #1694621)
- usb: misc: legousbtower: Fix buffers on stack
- usb: misc: legousbtower: Fix memory leak
- USB: ene_usb6250: fix DMA to the stack
- watchdog: pcwd_usb: fix NULL-deref at probe
- char: lp: fix possible integer overflow in lp_setup()
- USB: core: replace %p with %pK
- ARM: tegra: paz00: Mark panel regulator as enabled on boot
- tpm_crb: check for bad response size
- infiniband: call ipv6 route lookup via the stub interface
- dm btree: fix for dm_btree_find_lowest_key()
- dm raid: select the Kconfig option CONFIG_MD_RAID0
- dm bufio: avoid a possible ABBA deadlock
- dm bufio: check new buffer allocation watermark every 30 seconds
- dm cache metadata: fail operations if fail_io mode has been established
- dm bufio: make the parameter "retain_bytes" unsigned long
- dm thin metadata: call precommit before saving the roots
- dm space map disk: fix some book keeping in the disk space map
- md: update slab_cache before releasing new stripes when stripes resizing
- rtlwifi: rtl8821ae: setup 8812ae RFE according to device type
- mwifiex: pcie: fix cmd_buf use-after-free in remove/reset
- ima: accept previously set IMA_NEW_FILE
- KVM: x86: Fix load damaged SSEx MXCSR register
- KVM: X86: Fix read out-of-bounds vulnerability in kvm pio emulation
- regulator: tps65023: Fix inverted core enable logic.
- s390/kdump: Add final note
- s390/cputime: fix incorrect system time
- ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device
- ath9k_htc: fix NULL-deref at probe
- drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark
  calculations.
- drm/amdgpu: Make display watermark calculations more accurate
- drm/nouveau/therm: remove ineffective workarounds for alarm bugs
- drm/nouveau/tmr: ack interrupt before processing alarms
- drm/nouveau/tmr: fix corruption of the pending list when rescheduling an
  alarm
- drm/nouveau/tmr: avoid processing completed alarms when adding a new one
- drm/nouveau/tmr: handle races with hw when updating the next alarm time
- cdc-acm: fix possible invalid access when processing notification
- proc: Fix unbalanced hard link numbers
- of: fix sparse warning in of_pci_range_parser_one
- iio: dac: ad7303: fix channel description
- pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
- pid_ns: Fix 

[Yahoo-eng-team] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init -
0.7.9-113-g513e99e0-0ubuntu1~17.04.1

---
cloud-init (0.7.9-113-g513e99e0-0ubuntu1~17.04.1) zesty; urgency=medium

  * debian/update-grub-legacy-ec2: fix early exit failure no /etc/fstab
file. (LP: #1682160)
  * New upstream snapshot.
- nova-lxd: read product_name from environment, not platform.
  (LP: #1685810)
- Fix yum repo config where keys contain array values [Dylan Perry]
- template: Update debian backports template [Joshua Powers]
- rsyslog: replace ~ with stop [Joshua Powers] (LP: #1367899)
- Doc: add additional RTD examples [Joshua Powers]
- Fix growpart for some cases when booted with root=PARTUUID.
  (LP: #1684869)
- pylint: update output style to parseable [Joshua Powers]
- pylint: fix all logging warnings [Joshua Powers]
- CloudStack: Add NetworkManager to list of supported DHCP lease dirs.
  [Syed Mushtaq Ahmed]
- net: kernel lies about vlans not stealing mac addresses, when they do
  [Dimitri John Ledkov] (LP: #1682871)
- ds-identify: Check correct path for "latest" config drive
  [Daniel Watkins] (LP: #1673637)
- doc: Fix example for resolv.conf configuration.  [Jon Grimm]
- Fix examples that reference upstream chef repository.  [Jon Grimm]
- doc: correct grammar and improve clarity in merging documentation.
  [David Tagatac]
- doc: Add missing doc link to snap-config module. [Ryan Harper]
- snap: allows for creating cloud-init snap [Joshua Powers]
- DigitalOcean: assign IPv4ll address to lowest indexed interface.
  [Ben Howard] (LP: #1676908)
- DigitalOcean: configure all NICs presented in meta-data.
  [Ben Howard] (LP: #1676908)
- Remove (and/or fix) URL shortener references [Jon Grimm]
- HACKING.rst: more info on filling out contributors agreement.
- util: teach write_file about copy_mode option
  [Lars Kellogg-Stedman] (LP: #1644064)
- DigitalOcean: bind resolvers to loopback interface.
  [Ben Howard] (LP: #1676908)
- tests: fix AltCloud tests to not rely on blkid (LP: #1636531)

 -- Scott Moser   Thu, 27 Apr 2017 15:09:31 -0400

** Changed in: cloud-init (Ubuntu Zesty)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1682871

Title:
  attempts to rename vlans / vlans have addr_assign_type of 0 on kernel
  4.4

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Fix Released
Status in linux source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released

Bug 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.

   * 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 
;
# 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 
  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 

[Yahoo-eng-team] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init -
0.7.9-113-g513e99e0-0ubuntu1~16.10.1

---
cloud-init (0.7.9-113-g513e99e0-0ubuntu1~16.10.1) yakkety; urgency=medium

  * debian/update-grub-legacy-ec2: fix early exit failure no /etc/fstab
file. (LP: #1682160)
  * New upstream snapshot.
- nova-lxd: read product_name from environment, not platform.
  (LP: #1685810)
- Fix yum repo config where keys contain array values [Dylan Perry]
- template: Update debian backports template [Joshua Powers]
- rsyslog: replace ~ with stop [Joshua Powers] (LP: #1367899)
- Doc: add additional RTD examples [Joshua Powers]
- Fix growpart for some cases when booted with root=PARTUUID.
  (LP: #1684869)
- pylint: update output style to parseable [Joshua Powers]
- pylint: fix all logging warnings [Joshua Powers]
- CloudStack: Add NetworkManager to list of supported DHCP lease dirs.
  [Syed Mushtaq Ahmed]
- net: kernel lies about vlans not stealing mac addresses, when they do
  [Dimitri John Ledkov] (LP: #1682871)
- ds-identify: Check correct path for "latest" config drive
  [Daniel Watkins] (LP: #1673637)
- doc: Fix example for resolv.conf configuration.  [Jon Grimm]
- Fix examples that reference upstream chef repository.  [Jon Grimm]
- doc: correct grammar and improve clarity in merging documentation.
  [David Tagatac]
- doc: Add missing doc link to snap-config module. [Ryan Harper]
- snap: allows for creating cloud-init snap [Joshua Powers]
- DigitalOcean: assign IPv4ll address to lowest indexed interface.
  [Ben Howard] (LP: #1676908)
- DigitalOcean: configure all NICs presented in meta-data.
  [Ben Howard] (LP: #1676908)
- Remove (and/or fix) URL shortener references [Jon Grimm]
- HACKING.rst: more info on filling out contributors agreement.
- util: teach write_file about copy_mode option
  [Lars Kellogg-Stedman] (LP: #1644064)
- DigitalOcean: bind resolvers to loopback interface.
  [Ben Howard] (LP: #1676908)
- tests: fix AltCloud tests to not rely on blkid (LP: #1636531)

 -- Scott Moser   Thu, 27 Apr 2017 13:38:40 -0400

** Changed in: cloud-init (Ubuntu Yakkety)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1682871

Title:
  attempts to rename vlans / vlans have addr_assign_type of 0 on kernel
  4.4

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Fix Released
Status in linux source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released

Bug 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.

   * 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 
;
# 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 
  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 

[Yahoo-eng-team] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init -
0.7.9-113-g513e99e0-0ubuntu1~16.04.1

---
cloud-init (0.7.9-113-g513e99e0-0ubuntu1~16.04.1) xenial-proposed; 
urgency=medium

  * debian/update-grub-legacy-ec2: fix early exit failure no /etc/fstab
file. (LP: #1682160)
  * New upstream snapshot.
- nova-lxd: read product_name from environment, not platform.
  (LP: #1685810)
- Fix yum repo config where keys contain array values [Dylan Perry]
- template: Update debian backports template [Joshua Powers]
- rsyslog: replace ~ with stop [Joshua Powers] (LP: #1367899)
- Doc: add additional RTD examples [Joshua Powers]
- Fix growpart for some cases when booted with root=PARTUUID.
  (LP: #1684869)
- pylint: update output style to parseable [Joshua Powers]
- pylint: fix all logging warnings [Joshua Powers]
- CloudStack: Add NetworkManager to list of supported DHCP lease dirs.
  [Syed Mushtaq Ahmed]
- net: kernel lies about vlans not stealing mac addresses, when they do
  [Dimitri John Ledkov] (LP: #1682871)
- ds-identify: Check correct path for "latest" config drive
  [Daniel Watkins] (LP: #1673637)
- doc: Fix example for resolv.conf configuration.  [Jon Grimm]
- Fix examples that reference upstream chef repository.  [Jon Grimm]
- doc: correct grammar and improve clarity in merging documentation.
  [David Tagatac]
- doc: Add missing doc link to snap-config module. [Ryan Harper]
- snap: allows for creating cloud-init snap [Joshua Powers]
- DigitalOcean: assign IPv4ll address to lowest indexed interface.
  [Ben Howard] (LP: #1676908)
- DigitalOcean: configure all NICs presented in meta-data.
  [Ben Howard] (LP: #1676908)
- Remove (and/or fix) URL shortener references [Jon Grimm]
- HACKING.rst: more info on filling out contributors agreement.
- util: teach write_file about copy_mode option
  [Lars Kellogg-Stedman] (LP: #1644064)
- DigitalOcean: bind resolvers to loopback interface.
  [Ben Howard] (LP: #1676908)
- tests: fix AltCloud tests to not rely on blkid (LP: #1636531)

 -- Scott Moser   Thu, 27 Apr 2017 12:51:04 -0400

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1682871

Title:
  attempts to rename vlans / vlans have addr_assign_type of 0 on kernel
  4.4

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Committed
Status in linux source package in Zesty:
  Fix Released

Bug 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.

   * 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 
;
# 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 
  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 

[Yahoo-eng-team] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

[Kleber Sacilotto de Souza]

** Changed in: linux (Ubuntu Yakkety)
   Status: New => Fix Released

** Changed in: linux (Ubuntu Zesty)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1682871

Title:
  attempts to rename vlans / vlans have addr_assign_type of 0 on kernel
  4.4

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Committed
Status in linux source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Committed
Status in linux source package in Zesty:
  Fix Released

Bug 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.

   * 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 
;
# 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 
  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 
  Signed-off-by: David S. Miller 

   * 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//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

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1682871/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

[Scott Moser]

** Also affects: linux (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Zesty)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1682871

Title:
  attempts to rename vlans / vlans have addr_assign_type of 0 on kernel
  4.4

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Triaged
Status in cloud-init source package in Yakkety:
  New
Status in linux source package in Yakkety:
  New
Status in cloud-init source package in Zesty:
  New
Status in linux source package in Zesty:
  New

Bug 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.

   * 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 
;
# 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 
  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 
  Signed-off-by: David S. Miller 

   * 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//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

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1682871/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init -
0.7.9-113-g513e99e0-0ubuntu1

---
cloud-init (0.7.9-113-g513e99e0-0ubuntu1) artful; urgency=medium

  * New upstream snapshot.
- nova-lxd: read product_name from environment, not platform.
  (LP: #1685810)
- Fix yum repo config where keys contain array values
  [Dylan Perry] (LP: #1592150)
- template: Update debian backports template [Joshua Powers] (LP: #1627293)
- rsyslog: replace ~ with stop [Joshua Powers] (LP: #1367899)
- Doc: add additional RTD examples [Joshua Powers] (LP: #1459604)
- Fix growpart for some cases when booted with root=PARTUUID.
  (LP: #1684869)
- pylint: update output style to parseable [Joshua Powers]
- pylint: fix all logging warnings [Joshua Powers]
- CloudStack: Add NetworkManager to list of supported DHCP lease dirs.
  [Syed Mushtaq Ahmed]
- net: kernel lies about vlans not stealing mac addresses, when they do
  [Dimitri John Ledkov] (LP: #1682871)
- ds-identify: Check correct path for "latest" config drive
  [Daniel Watkins] (LP: #1673637)
- doc: Fix example for resolve.conf configuration.
  [Jon Grimm] (LP: #1531582)
- Fix examples that reference upstream chef repository.
  [Jon Grimm] (LP: #1678145)
- doc: correct grammar and improve clarity in merging documentation.
  [David Tagatac]
- doc: Add missing doc link to snap-config module. [Ryan Harper]
- snap: allows for creating cloud-init snap [Joshua Powers]
- DigitalOcean: assign IPv4ll address to lowest indexed interface.
  [Ben Howard]
- DigitalOcean: configure all NICs presented in meta-data. [Ben Howard]
- Remove (and/or fix) URL shortener references [Jon Grimm] (LP: #1669727)
- HACKING.rst: more info on filling out contributors agreement.
  [Scott Moser]
- util: teach write_file about copy_mode option
  [Lars Kellogg-Stedman] (LP: #1644064)
- DigitalOcean: bind resolvers to loopback interface. [Ben Howard]
- tests: fix AltCloud tests to not rely on blkid (LP: #1636531)

 -- Scott Moser   Tue, 25 Apr 2017 16:34:08 -0400

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1682871

Title:
  attempts to rename vlans / vlans have addr_assign_type of 0 on kernel
  4.4

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Triaged

Bug 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 
  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 
  Signed-off-by: David S. Miller 

   * 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//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

To manage notifications about this bug go to: