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: | enc: Link state is up-to-date | enc: found matching network '/run/systemd/network/enc.network' | enc: Started LLDP. | enc: Discovering IPv6 routers | NDisc CLIENT: Start Router Solicitation | NDisc CLIENT: Sent Router Solicitation | ens: Link state is up-to-date | ens: Unmanaged | eth0: Link state is up-to-date | eth0: Unmanaged | lo: Link state is up-to-date | lo: Unmanaged | enc: Could not drop address: No such process | NDisc CLIENT: Sent Router Solicitation | NDisc CLIENT: Sent Router Solicitation | DHCPv6 CLIENT: Started in Managed mode | enc: Configured | DHCPv6 CLIENT: Sent SOLICIT | DHCPv6 CLIENT: Next retransmission in 1s | DHCPv6 CLIENT: Sent SOLICIT | DHCPv6 CLIENT: Next retransmission in 2s | DHCPv6 CLIENT: Sent SOLICIT | DHCPv6 CLIENT: Next retransmission in 4s | DHCPv6 CLIENT: Sent SOLICIT | DHCPv6 CLIENT: Next retransmission in 9s | DHCPv6 CLIENT: Sent SOLICIT | DHCPv6 CLIENT: Next retransmission in 17s | DHCPv6 CLIENT: Sent SOLICIT | DHCPv6 CLIENT: Next retransmission in 35s | DHCPv6 CLIENT: Sent SOLICIT | DHCPv6 CLIENT: Next retransmission in 1min 13s 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)
signature.asc
Description: PGP signature