Bug#815884: does not retry IPv6 router solicitations

Wed Jul 6 09:50:53 BST 2016

Control: reopen -1
Control: tag -1 moreinfo unreproducible

while we reverted the change in 229, we don't want to carry the reversion
forever. I forwarded this upstream to
https://github.com/systemd/systemd/issues/3664, and will now play relay :-)

I reopen the bug as we should investigate/fix this for good.

Marc Haber [2016-02-25 11:41 +0100]:
> systemd 229 has taken over the code to send and accept router
> solicitations in IPv6. Unfortunately, it does only send a single RS
> immediately after the link comes up, and does not retry if no RA comes
> in.

I'm trying to understand this bug, so I tried to reproduce it in a VM
with no external network (so that solicitations aren't being answered
by other interfaces) and just a veth pair. This is current Debian sid.

First, I set up a "client" and "server" veth pair:

| ip link add name enc type veth peer name ens
| ip a add 2600::1/64 dev ens
| ip  link set ens up

Then I added a networkd config for this:

| mkdir -p /run/systemd/network
| cat <<EOF > /run/systemd/network/enc.network
| [Match]
| Name=enc
|
| [Network]
| IPv6AcceptRouterAdvertisements=yes
| EOF

There is no radvd or dnsmasq or anything else running which would
actually respond to router solicitations or generate RAs, so AFAIUI
this should cause several retries.

Now I started networkd with

| SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

and watched what was going on on the "server" end with

| tcpdump -i ens

I tried this with networkd 229, networkd 230 (upstream or the packages
in https://people.debian.org/~mpitt/tmp/systemd-userspace-ndisc/) and
sid's networkd with the reverted patch so that it goes back to the
kernel behaviour.

networkd actually tries a RS three times, but from then on only
regularly retries DHCPv6 soliciations, no router solicitations:

This corresponds to what I see in tcpdump:

| 10:30:54.140351 IP6 sid > ip6-allrouters: ICMP6, router solicitation, length 16
| 10:30:58.211511 IP6 sid > ip6-allrouters: ICMP6, router solicitation, length 16
| 10:31:02.461491 IP6 sid > ip6-allrouters: ICMP6, router solicitation, length 16
| 10:31:06.712032 IP6 sid.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
| 10:31:07.899086 IP6 sid.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
| 10:31:10.231396 IP6 sid.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
| 10:31:14.812014 IP6 sid.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
| 10:31:24.079965 IP6 sid.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
| 10:31:41.873169 IP6 sid.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
| 10:32:17.794287 IP6 sid.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit

This behaves pretty well the same in all three cases, i. e. it doesn't
seem to matter whether the kernel or networkd handles RS/RA. So I'm
afraid I cannot confirm that the kernel retries, and thus this isn't a
regression in networkd.

But maybe I'm misunderstanding what you mean, or this only affects
particular hardware combinations, or there is something else going
on.

So please: Can you install the packages on
https://people.debian.org/~mpitt/tmp/systemd-userspace-ndisc/ and
check if you still get the bad behaviour with those? If so, can you
please run networkd in debug mode and a parallel tcpdump like above
and attach the logs?

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20160706/875ada41/attachment.sig>