[Pkg-utopia-maintainers] Bug#668885: network-manager: change action when RDNSS expires
Per Carlson
pelle at hemmop.com
Sun Apr 15 10:52:10 UTC 2012
Package: network-manager
Version: 0.9.4.0-1
Severity: wishlist
Tags: upstream ipv6
When the RDNSS info in a RA expires, N-M flaps the link and causes loss
of connectivity for *both* IPv4 and IPv6 (IPv6 only would be bad
enough).
>From /var/log/daemon.log:
Apr 14 20:41:50 apu NetworkManager[1364]: <debug> [1334428910.668907]
[nm-ip6-manager.c:277] rdnss_expired(): (wlan0): IPv6 RDNSS information expired
Apr 14 20:41:50 apu NetworkManager[1364]: <debug> [1334428910.668996]
[nm-ip6-manager.c:312] set_rdnss_timeout(): (wlan0): removing expired
RA-provided nameserver 2001:db8:2001::2:53
Apr 14 20:41:50 apu NetworkManager[1364]: <debug> [1334428910.938763]
[nm-system.c:1168] nm_sy stem_iface_flush_routes(): (wlan0): flushing
routes ifindex 3 family UNSPEC (0)
Apr 14 20:41:51 apu NetworkManager[1364]: <debug> [1334428911.86512]
[nm-netlink-utils.c:360] dump_route(): route idx 1 family INET6 (10)
addr 0:0:4100::2f6f:7267/0
Apr 14 20:41:51 apu NetworkManager[1364]: <debug> [1334428911.86580]
[nm-netlink-utils.c:360] dump_route(): route idx 1 family INET6 (10)
addr ::1/128
Apr 14 20:41:51 apu NetworkManager[1364]: <debug> [1334428911.86613]
[nm-netlink-utils.c:360] dump_route(): route idx 1 family INET6 (10)
addr 0:0:5100::/0
Apr 14 20:41:51 apu NetworkManager[1364]: <debug> [1334428911.87811]
[nm-system.c:196] sync_addresses(): (wlan0): syncing addresses (family 0)
Apr 14 20:41:51 apu NetworkManager[1364]: <debug> [1334428911.87916]
[nm-system.c:249] sync_addresses(): (wlan0): removing address
'192.168.1.138/24'
Apr 14 20:41:51 apu wpa_supplicant[1384]: CTRL-EVENT-DISCONNECTED
bssid=00:00:00:00:00:00 reason=3
Apr 14 20:41:54 apu wpa_supplicant[1384]: Trying to authenticate with
00:18:f8:f2:08:ac (SSID='boork-boork' freq=2462 MHz)
Apr 14 20:41:54 apu wpa_supplicant[1384]: Trying to associate with
00:18:f8:f2:08:ac (SSID='bo ork-boork' freq=2462 MHz)
Apr 14 20:41:54 apu wpa_supplicant[1384]: Associated with 00:18:f8:f2:08:ac
Apr 14 20:41:54 apu wpa_supplicant[1384]: WPA: Key negotiation completed
with 00:18:f8:f2:08:ac [PTK=CCMP GTK=CCMP]
Apr 14 20:41:54 apu wpa_supplicant[1384]: CTRL-EVENT-CONNECTED -
Connection to 00:18:f8:f2:08:ac completed (reauth) [id=0 id_str=]
End of /var/log/daemon.log
I would like to propose a change in the behaviour whenever a RDNSS entry
expires to circumvent this unneccesary link flap. The change can be done
two ways, which both can be implemented at the same time.
Alternative 1:
In the RDNSS RFC (6106) in the description of the RDNSS option (section
5.1) and specifically the Lifetime field it written: "Hosts MAY send a
Router Solicitation to ensure the RDNSS information is fresh before the
interval expires.".
I think this is a very polite way to handle expiring RDNSS entries.
Alternative 2:
When experimenting setting different lifetimes on the RDNSS entry, I
noticed that when changing it from non-nero to zero (0) the RDNSS entry
where removed from /etc/resolv.conf but the link didn't flap. I'm
suggesting to change the behaviour of an expired lifetime to mimic the
one when changed to zero.
This change is inline with the procedure in RFC6106 (section 6.2):
Step (b): "If the RDNSS address already exists in the DNS Server List
and the RDNSS option's Lifetime field is set to zero, delete the
corresponding RDNSS entry from both the DNS Server List and the Resolver
Repository..."
and
"The handling of expired RDNSSes is as follows: Whenever an entry expires
in the DNS Server List, the expired entry is deleted from the DNS Server
List, and also the RDNSS address corresponding to the entry is deleted
from the Resolver Repository."
Background:
I've tried to diagnose link flaps on my wireless home network some time
now. There havn't been any issues with the connectivity on other
platforms (Android, iPhone, Win7) or when disabling IPv6 (ignore in
N-M).
After enabling debugging og N-M, done wireshark traces, and seen the
expiring RDNSS entries I've concluded this is (most likely) is caused by
lost RA's. On some occurances the received RA's have been almost 1000s
apart. As I did follow the recomendation in the RFC and set the lifetime
value just between MaxRtrAdvInterval and 2*MaxRtrAdvInterval, 900s that is,
I now know why the RDNSS expired. As a workaround, I've set the lifetime to
1200s and haven't had a single link flap since.
Nevertheless, if the procedure is changed in N-M those problems would
most likely been circumvented. In a wireless environment a RA can easily
be lost and that shouldn't result in a link flap causing lost
connectivity for both IPv4 and IPv6.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (600, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages network-manager depends on:
ii adduser 3.113+nmu1
ii dbus 1.5.12-1
ii dpkg 1.16.2
ii isc-dhcp-client 4.2.2.dfsg.1-4
ii libc6 2.13-27
ii libdbus-1-3 1.5.12-1
ii libdbus-glib-1-2 0.98-1
ii libgcrypt11 1.5.0-3
ii libglib2.0-0 2.30.2-6
ii libgnutls26 2.12.18-1
ii libgudev-1.0-0 175-3.1
ii libnl-3-200 3.2.7-2
ii libnl-genl-3-200 3.2.7-2
ii libnl-route-3-200 3.2.7-2
ii libnm-glib4 0.9.4.0-1
ii libnm-util2 0.9.4.0-1
ii libpolkit-gobject-1-0 0.104-2
ii libuuid1 2.20.1-4
ii lsb-base 4.1+Debian0
ii udev 175-3.1
ii wpasupplicant 0.7.3-6
Versions of packages network-manager recommends:
ii crda 1.1.2-1
ii dnsmasq-base 2.60-2
ii iptables 1.4.12.2-1
ii modemmanager 0.5.2.0-1
ii policykit-1 0.104-2
ii ppp 2.4.5-5
Versions of packages network-manager suggests:
ii avahi-autoipd 0.6.31-1
-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=true
[logging]
level=debug
domains=IP6
-- no debconf information
More information about the Pkg-utopia-maintainers
mailing list