Wifi disconnect/reconnects fairly often (from multiple times an hour to multiple times per day) because of ip-config-unavailable

[Impact]
Affects IPv6 users on dual-stack or single-ipv6-stack networks; causes frequent disconnects if a sufficient number of packets are missed (especially towards the end of the RDNSS/DNSSL entry lifetime). Patch is pretty self-contained and only affects IPv6, only in the case of SLAAC (stateless autoconfiguration) since DHCPv6-based networks provide DNS information in a different manner.

[Development Fix]
Package network-manager 0.9.4.0-0ubuntu5 which fixes all of the same bugs targetted to be fixed with this SRU; including bug 993379 and bug 988183. Also tested in a PPA (ppa:mathieu-tl/nm) prior to upload to quantal and precise-proposed.

[Stable Fix]
The small patch based on the patch provided for testing in the linked RedHat bug; which is the exact same (no changes required) patch as revised from the original (from the redhat bug and attached to this bug report) as was uploaded to Quantal after testing in a PPA. Adds a method for renewing/refreshing RDNSS and DNSSL data from Router Advertisements. At lifetime/2 a first router solicitation will be sent to try and force an update; if no response is received the same process (timeout/2) is applied again to send another solicitation message to routers asking for a RA, until one is received and refreshes RDNSS/DNSSL data or until data expiry.

[Test case]
Requires a working IPv6 setup: see below.
1) Connect to an IPv6 network that provides RDNSS data. (DNSSL uses the same procedure but is not available in current Precise kernels)
2) Observe whether the connection is stable.

[Regression Potential]
Only affects IPv6 SLAAC, which means IPv6 could be disabled to mitigate any issues encountered. Users could be affected by a (minimal) increase in the number of packets sent over the network due to the sending of Router Solicitation messages. On high-latency links this may cause issues. New RS messages may cause RAs giving new IPv6 addresses more quickly than anticipated.

---

Testing IPV6 RDNSS with radvd:
You can use a configuration similar to the following, on a router where the vlan2 interface would be the outside interface:

interface br0 {
 MinRtrAdvInterval 3;
 MaxRtrAdvInterval 10;
 AdvLinkMTU 1280;
 AdvSendAdvert on;
 prefix 0:0:0:1::/64 {
 AdvOnLink on;
 AdvAutonomous on;
 AdvValidLifetime 86400;
 AdvPreferredLifetime 86400;
 Base6to4Interface vlan2;
 };
 RDNSS 2001:503:ba3e::2:30 2001:500:2d::d {};
 };

This particular setup uses 6to4 to provide IPv6 connectivity; and announces a.root-servers.net and d.root-servers.net as DNS nameservers to use.

In control of the router one could kill the radvd daemon to simulate lost packets and observe attempts to refresh RDNSS data, and bring the daemon back up again to see how with a RA the RDNSS information gets refreshed.

Packet captures are also useful to observe the behavior.

---
Original bug report description:

To start with, let me confirm that I do NOT have any message in my kernel log complaining about the kernel not being able to set the default IPv6 route, so that's a different bug from the what you're probably thinking about ;)

This one happens every few minutes or every few hours, as far as I can tell, only on wireless networks (for a yet unknown reason) and only on dual-stack networks.

I reproduced it on a variety of equipment (3 laptops, 2 with 2 different intel wireless chips, one with atheros) and on 4 different brands of access points. Only thing in common, the network configuration is almost identical.
That's a standard dual-stack setup with IPv4 provided over DHCP and IPv6 through radvd (SLAAC) with RDNSS set.

I'm attaching a debug log. Look for "ip-config-unavailable" to spot the few occurrences of the bug in it.

This most likely is the same bug as described in: https://bugzilla.redhat.com/show_bug.cgi?id=753482