$ dpkg -l | grep 229-4
ii libpam-systemd:amd64 229-4ubuntu21
amd64 system and service
manager - PAM module
ii libsystemd-dev:amd64 229-4ubuntu21
amd64 systemd utility library -
development files
ii libsystemd0:amd64 229-4ubuntu21
amd64 systemd utility library
ii libudev-dev:amd64 229-4ubuntu21
amd64 libudev development files
ii libudev1:amd64 229-4ubuntu21
amd64 libudev shared library
ii systemd 229-4ubuntu21
amd64 system and service manager
ii systemd-sysv 229-4ubuntu21
amd64 system and service
manager - SysV links
ii udev 229-4ubuntu21
amd64 /dev/ and hotplug
management daemon
Executed the attached regression-apr.sh script against my eht0
interface, all 4 test cases reported good. Previously at least one of
them failed.
** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done verification-done-xenial
** Description changed:
[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.
+
+ [Affected Users]
+
+ * Those who use networkd
+
+ * Do not use netplan (as that sets mtubytes in the .link files, not in the
.network)
+
+ * Specify MTUBytes in .network file (not in the .link file)
[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
A test script is attached, that given an interface can abuse it to
validate all of the above.
[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
--
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:
Fix Committed
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.
[Affected Users]
* Those who use networkd
* Do not use netplan (as that sets mtubytes in the .link files, not in the
.network)
* Specify MTUBytes in .network file (not in the .link file)
[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
A test script is attached, that given an interface can abuse it to
validate all of the above.
[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
