GNOME Bugzilla – Bug 707155
ipv6: wait for link-local address and/or ask the kernel to add it when appropriate
Last modified: 2013-11-08 08:08:06 UTC
For method=link-local we should be able to wait for the IPv6 link-local address to be added by the kernel and perform DAD. When it's no longer tentative, link-local method is considered complete. This will (1) fix a regression caused by recent changes related to nm-platform/nm-rdisc and (2) improve on them. Also method=auto would use that so that router discovery is not started before link-local address is usable. Also it brings up a question what to do with method=link-local when method=disabled is added. I still think those should be eventually merged and separate options should be added for anything that doesn't affect global address configuration.
(In reply to comment #0) > Also it brings up a question what to do with method=link-local when > method=disabled is added. I still think those should be eventually merged and > separate options should be added for anything that doesn't affect global > address configuration. As link-local isn't a global configuration feature, we should treat it as a separate option: [ipv6] link-local = undefined|disabled|enabled undefined: keep interface-specific 'disable_ipv6' as is disabled: set interface-specific 'disable_ipv6' to 1 enabled: set interface-specific 'disable_ipv6' to 0 AFAIK the kernel doesn't allow us to specifically enable/disable IPv6 link-local adresses and therefore we always have to disable IPv6 in its entirety. If kernel allowed us to disable link-local address configuration specifically, we could still add manual IPv6 configuration to the interface. See also: https://bugzilla.gnome.org/show_bug.cgi?id=682932#c5
From duplicate bug report: Dan Winship [reporter] [NetworkManager developer] 2013-10-09 15:25:39 UTC I frequently see this in the journal when activating a connection: NetworkManager[31521]: <error> [1381331854.884459] [rdisc/nm-lndp-rdisc.c:194] send_rs(): (wlp3s0): cannot send router solicitation: -99. 99 is EADDRNOTAVAIL. Perhaps a race condition involving us trying to send an RS before the kernel finishes assigning the link-local address?
*** Bug 709743 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > 99 is EADDRNOTAVAIL. Perhaps a race condition involving us trying to send an RS > before the kernel finishes assigning the link-local address? Indeed a result of using the link-local before it's ready.
Yeah, we should definitely be waiting for the LL address. The old ip6-manager used to do that but since it was replaced with the rdisc stuff (which is better) that's not happening anymore. I don't recall any kernel interfaces to explicitly refresh the IPv6LL address though, apart from bouncing the interface with IFF_UP, yet another problem with the close tying of IPv6 addressing to interface flags that shouldn't exist. Maybe another one for jpirko or thaller to work on kernel-side? At least this one we could hack around by generating an IPv6LL address in NM until the kernel APIs got added.
for the standard case (ie, maybe not the case you were seeing today), all we have to do is check if the device already has a LL address, and if not, wait for the appropriate NMPlatform::ip6-address-added signal before starting
(In reply to comment #6) > for the standard case (ie, maybe not the case you were seeing today), all we > have to do is check if the device already has a LL address, and if not, wait > for the appropriate NMPlatform::ip6-address-added signal before starting Actually the mere existence of LL address doesn't mean it's usable. If it's not yet usable, we shouldn't report it to other applications and we shouldn't start using it. Maybe you meant it that way and I'm just overly careful. (In reply to comment #5) > At least this > one we could hack around by generating an IPv6LL address in NM until the kernel > APIs got added. Hmm, that's indeed ugly. I'll try to find time to talk to Thomas and Jirka and see what they already know.
Fix pushed to upstream master: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c4a087c36d34e584a48b6b866fc3c12f248f8512 Now we wait for both 'link-local' and 'auto' to find a LL address before proceeding. (In reply to comment #7) > Actually the mere existence of LL address doesn't mean it's usable. If it's not > yet usable, we shouldn't report it to other applications and we shouldn't start > using it. Maybe you meant it that way and I'm just overly careful. A previous commit also addeds the IFA_F_* flags to NMPlatformIP6Address, so that we can wait for the LL address to no longer be tentative. Closing this bug now...
Just please confirm that we are waiting for DAD to finish, not only for the address to exist, otherwise the bug according to bug description is not fixed.
(In reply to comment #9) > Just please confirm that we are waiting for DAD to finish, not only for the > address to exist, otherwise the bug according to bug description is not fixed. Well, yeah, that's how it should be and what I meant with the IFA_F_* flags remark. We wait until there is a LL address, without IFA_F_TENTATIVE flag. Isn't that good enough? Thomas
(In reply to comment #10) > We wait until there is a LL address, without IFA_F_TENTATIVE flag. > Isn't that good enough? Yes, great, just wanted to have it confirmed. Thanks.