GNOME Bugzilla – Bug 669302
NetworkManager times out too early when waiting for IPv6 address autoconfiguration on wireless networks
Last modified: 2012-08-16 20:12:57 UTC
Description of problem: I rolled out IPv6 the other day at my house and found it worked great on all my wired systems, but my wireless ipv6 enabled systems all of a sudden started getting disconnected from the wireless network, I did some digging and found that NetworkManager seems to have 2 shortcommings in how it handles wireless IPv6 autoconfiguration: 1) The timeout that it sets for address autoconfiguration is hard coded to 20 seconds. This may be acceptible for some situations, but it ignores the fact that router advertisement daemons have a configurable advertisement period. If the advert period on radvd is greater than than 20 seconds, we risk getting erroneously disconnected from the network simply because the host system hasn't seen an RA frame yet. Granted we nominally should send out an RS on link up, but if that gets lots or is otherwise not responded to, this breaks. That timeout should be configurable so that it can be set in accordance with the local router advert daemon. 2) The timeout in question doesn't take DAD time into account. It seems NM moves its addrconf state for in interface to a completed state only after it passes duplicate address detection. Dad can last for a configurable length of time, and on wireless networks, because of section 4.1 here: http://tools.ietf.org/html/draft-daniel-ipv6-over-wifi-01 DAD _must_ run for the maximum possible time on that interface, which, in conjunction with the above, can easily surpass the NM hard coded addr autoconf timeout. Once we have an address, and DAD has begun (this can be determined by thje interrogation of the tentative flag in rtnetlink for an address), NM should wait indefinately, untill the address is removed (the dad failed case), or the tentative flag is cleared (the dad succeded case). Version-Release number of selected component (if applicable): all How reproducible: frequently Steps to Reproduce: 1. configure a local radvd daemon to advertize a global prefix, and configure its minimum advertisement interval to be > 20 seconds 2. configure a wireless client to enable DAD on the wireless interface via echo 1 > /proc/sys/net/ipv6/<ifc>/accept_dad 3.Make sure NM is configured to attach to a wireless AP that can forward RA's from the router over the wireless link, and make sure that that networks is set to automatic in the IPv6 tab in NM. 4. Bring up that wireless link in NM Actual results: NM will indicate autoconfiguration has begun, and will time out. Expected results: NM will wait at least as long as the Routers RA min interval before timing out, and as long as necessecary after dad has begin before deciding address autoconfig has failed
„Granted we nominally should send out an RS on link up, but if that gets lots or is otherwise not responded to, this breaks. That timeout should be configurable so that it can be set in accordance with the local router advert daemon.“ This seems to be one of the many timing problems with SLAAC. But anyway, the system should always be sending Router Solicitation and it should not get lost. This particular problem arises only with links that have problem with multicast frames (as Router Solicitation is sent to a link-local multicast). These are usually wireless and depend on your network equipment. This sort of bug is not easy to fix right now. (Raising the timeout high above MinRtrAdvInterval/MaxRtrAdvInterval is an ugly workaround.)
The maximum delay for dad is configurable, just not as as a single, easily packaged value, because the RFC 4681 and RFC 4682 mandate that the retransmission timer for neighbor solicitation values be variable. That said, for dad, the retransmission time is bounded, by the ndisc retrans time value and by the number of dad transmits that are configured. It should be pretty straightforward for you, on a given interface to lookup: /proc/sys/net/ipv6/conf/<interface>/router_solicitation_interval /proc/sys/net/ipv6/conf/interfaace>/dad_transmits /proc/sys/net/ipv6/neigh/<interface>/retrans_time DAD should complete on <interface> within: router_solicitation_interval+(dad transmits * (retrans_time/1000)) seconds Given the lossy nature of wireless, you can double that and be fairly safe on SLAAC addresses. That doesn't seem to0 hard to me.
Does it mean that the client is not recieving a Router Advertisement at all? http://tools.ietf.org/html/rfc4861#section-6.2.1 MinRtrAdvInterval The minimum time allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds. MUST be no less than 3 seconds and no greater than .75 * MaxRtrAdvInterval. Default: 0.33 * MaxRtrAdvInterval If MaxRtrAdvInterval >= 9 seconds; otherwise, the Default is MaxRtrAdvInterval. That means MinRtrAdvInterval shoud *never* be a problem when using Router Solicitations. The router should respond to the RS. I guess we need a tcpdump of RA and RS of your case. Please also note that the upcoming 0.9.6 release will include important IPv6-related changes. You can build from Git if you want to test the changes now.
Will reopen if you can reproduce with 0.9.6 with extensively modified IPv6 code.