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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to