** Description changed: [Impact] - * Incomplete cherrypick of ARP functionality in networkd resulted in an - undesired side-effect, specifically NOARP flag started to be applied - unconditionally, specifically when it should not have, resulting in loss - of network connectivity. + * Setting [Link] MTUBytes= in .network file has a side-effect of + overflowing and setting NOARP flag. This is not intended behaviour / + regression. - * This is a regression in -updates. + * Trying to fix above by setting ARP=on fails to work as tristate is + incorrectly acted upon by unconditionally adding NOARP flag + + * This is a regression in -updates. [Test Case] - * Configure a bond using networkd - * Upgrade - * Make sure NOARP flag is not set on the interfaces / bond + * Configure an ethernet device with a .network file alone + * e.g. Match by mac address and perform DHCP + * Add [Link] section to the .network file which changes MTUBytes + * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output + + + * Further add ARP=off to that .network file, the link should have NOARP flag + * Further add ARP=on to that .network file, the link should not have NOARP flag [Regression Potential] - * This is an upstream fix for this issue. + * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] - - * Upstream fix + + * Upstream fixes + https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch - - * Original bug report + + * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> post-upgrade: eth0: <BROADCAST,MULTICAST,NOARP,SLAVE,UP,LOWER_UP> eth1: <BROADCAST,MULTICAST,NOARP,SLAVE,UP,LOWER_UP> bond0: <BROADCAST,MULTICAST,NOARP,MASTER,UP,LOWER_UP> Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Invalid Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Invalid Status in systemd source package in Artful: Invalid Status in systemd source package in Bionic: Invalid Bug description: [Impact] * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag * This is a regression in -updates. [Test Case] * Configure an ethernet device with a .network file alone * e.g. Match by mac address and perform DHCP * Add [Link] section to the .network file which changes MTUBytes * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output * Further add ARP=off to that .network file, the link should have NOARP flag * Further add ARP=on to that .network file, the link should not have NOARP flag [Regression Potential] * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] * Upstream fixes https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> post-upgrade: eth0: <BROADCAST,MULTICAST,NOARP,SLAVE,UP,LOWER_UP> eth1: <BROADCAST,MULTICAST,NOARP,SLAVE,UP,LOWER_UP> bond0: <BROADCAST,MULTICAST,NOARP,MASTER,UP,LOWER_UP> Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
