[Bug 1845909] Re: [SRU] IPv6 link local address is assigned even when LinkLocalAddressing=no|ipv4
Dan Streetman
ddstreet at canonical.com
Wed Jan 22 01:29:30 UTC 2020
** Description changed:
[impact]
- when a networkd interface is configured with LinkLocalAddressing=no,
- networkd still assigns a link-local address to it
+ in some situations when a networkd interface is configured with
+ LinkLocalAddressing=no, networkd still assigns a link-local address to
+ it
[test case]
see comment 3.
note I was only able to reproduce this at boot time; if the vlan
interface is removed (i.e. 'sudo ip l del pppoe') and then networkd
restarted, the pppoe interface is created and does not have a link-local
- address.
+ address. This is due to this bug being triggered by timing, as a vlan
+ interface is raised by the kernel when its parent interface is raised,
+ in this case by networkd itself.
[regression potential]
- this moves the point when ipv6ll is configured; regressions would most
- likely involve failure to correctly configure an ipv6ll address when
- desired.
+ this changes how ipv6ll addresses are managed and dropped, as well as
+ changing when foreign addresses are dropped (later in config process).
+ Any regressions would likely be around incorrectly setting ipv6ll
+ addresses, or complete failure to complete interface configuration.
+
+ [scope]
+
+ this is fixed upstream by:
+ https://github.com/systemd/systemd/pull/13927
+
+ and also requires the upstream PR referenced in the original description:
+ upstream patch: https://github.com/systemd/systemd/pull/13565
+
+ this is required for focal (uploaded already), eoan, and bionic. It may
+ be required for xenial.
[other info]
- this bug was attempted to be fixed by 'debian/patches/networkd-honour-LinkLocalAddressing.patch' from upstream issue 9890, using a commit that does not correctly fix the issue and was never accepted upstream:
- https://github.com/systemd/systemd/issues/9890#issuecomment-455168751
-
- this SRU completely reverts that patch, and adds the correct fix which
- was merged upstream:
- https://github.com/systemd/systemd/commit/0e2fdb83bb5e22047e0c7cc058b415d0e93f02cf
-
- that commit is already included in Eoan so this sru is needed only for
- Disco.
+ Note, the original description below is incorrect, the issue/patch it
+ references is not enough to fix this issue.
original description:
--
upstream issue: https://github.com/systemd/systemd/issues/12886
upstream patch: https://github.com/systemd/systemd/pull/13565
The upstream fix will be available in systemd 244.
Backport please. Thanks.
** Changed in: systemd (Ubuntu Eoan)
Status: Incomplete => In Progress
** Changed in: systemd (Ubuntu Bionic)
Status: Incomplete => In Progress
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1845909
Title:
[SRU] IPv6 link local address is assigned even when
LinkLocalAddressing=no|ipv4
Status in systemd:
New
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
In Progress
Status in systemd source package in Focal:
In Progress
Bug description:
[impact]
in some situations when a networkd interface is configured with
LinkLocalAddressing=no, networkd still assigns a link-local address to
it
[test case]
see comment 3.
note I was only able to reproduce this at boot time; if the vlan
interface is removed (i.e. 'sudo ip l del pppoe') and then networkd
restarted, the pppoe interface is created and does not have a link-
local address. This is due to this bug being triggered by timing, as
a vlan interface is raised by the kernel when its parent interface is
raised, in this case by networkd itself.
[regression potential]
this changes how ipv6ll addresses are managed and dropped, as well as
changing when foreign addresses are dropped (later in config process).
Any regressions would likely be around incorrectly setting ipv6ll
addresses, or complete failure to complete interface configuration.
[scope]
this is fixed upstream by:
https://github.com/systemd/systemd/pull/13927
and also requires the upstream PR referenced in the original description:
upstream patch: https://github.com/systemd/systemd/pull/13565
this is required for focal (uploaded already), eoan, and bionic. It
may be required for xenial.
[other info]
Note, the original description below is incorrect, the issue/patch it
references is not enough to fix this issue.
original description:
--
upstream issue: https://github.com/systemd/systemd/issues/12886
upstream patch: https://github.com/systemd/systemd/pull/13565
The upstream fix will be available in systemd 244.
Backport please. Thanks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1845909/+subscriptions
More information about the foundations-bugs
mailing list