Debian Bug report logs - #815884
does not retry IPv6 router solicitations

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: does not retry IPv6 router solicitations

Date: Thu, 25 Feb 2016 11:41:31 +0100

Package: systemd
Version: 229-1
Severity: important

Hi,

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.

Unfortunately, bigger switches do not immediately begin forwarding
packets after a link was brought up but take a few seconds before the
port actually enters forwarding state. On Cisco Catalyst Switches in
default configuration, this typically takes 30 seconds until the port
is set to spanning-tree portfast. On HP ProCurve switches, it takes 6
to 10 seconds unless LACP and STP negotiation is completed. LACP can
be turned off, STP cannot.

When a system running IPv6 with systemd 229 is connected to such a
switch, the system doesn't get IPv6 on startup, and it doesn't acquire
IPv6 on the next regular RA because of #815793. This makes IPv6
completely unuseable.

Going back to systemd 226 fixes the issue.

With systemd 229, if one forces the switch port in the forwarding
state by inserting a dumb switch between the "big" switch and the
Linux system, one sees the RA sent by systemd, and IPv6 works. But one
cannot possible use dumb switches just to fix systemd's shortcomings.

This is a showstopper for IPv6 with systemd. I would like to ask the
Debian systemd maintainers to use their discretion to set either this
or #815793's severity to any RC value, as both behavioral anomalities
of systemd are blatant violations of the IPv6 RFCs.

systemd should only migrate to testing when it doesn't break IPv6 any
more.

Greetings
Marc

Message #12 received at 815884-close@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: 815884-close@bugs.debian.org

Subject: Bug#815884: fixed in systemd 229-2

Date: Sun, 28 Feb 2016 23:53:07 +0000

Source: systemd
Source-Version: 229-2

We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 815884@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Martin Pitt <mpitt@debian.org> (supplier of updated systemd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sun, 28 Feb 2016 22:16:12 +0100
Source: systemd
Binary: systemd systemd-sysv systemd-container systemd-journal-remote systemd-coredump libpam-systemd libnss-myhostname libnss-mymachines libnss-resolve libsystemd0 libsystemd-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb systemd-dbg
Architecture: source amd64
Version: 229-2
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Changed-By: Martin Pitt <mpitt@debian.org>
Description:
 libnss-myhostname - nss module providing fallback resolution for the current hostname
 libnss-mymachines - nss module to resolve hostnames for local container instances
 libnss-resolve - nss module to resolve names via systemd-resolved
 libpam-systemd - system and service manager - PAM module
 libsystemd-dev - systemd utility library - development files
 libsystemd0 - systemd utility library
 libudev-dev - libudev development files
 libudev1   - libudev shared library
 libudev1-udeb - libudev shared library (udeb)
 systemd    - system and service manager
 systemd-container - systemd container/nspawn tools
 systemd-coredump - tools for storing and retrieving coredumps
 systemd-dbg - system and service manager (debug symbols)
 systemd-journal-remote - tools for sending and receiving remote journal logs
 systemd-sysv - system and service manager - SysV links
 udev       - /dev/ and hotplug management daemon
 udev-udeb  - /dev/ and hotplug management daemon (udeb)
Closes: 814566 814667 815020 815586 815793 815884 816132
Changes:
 systemd (229-2) unstable; urgency=medium
 .
   * time-util: map ALARM clockids to non-ALARM clockids in now(), to work on
     architectures which don't support CLOCK_BOOTTIME_ALARM. Fixes FTBFS on
     many architectures.
   * debian/systemd.postinst: Add missing newline to /etc/adjtime migration.
     (See #699554)
   * debian/systemd.postinst: Only try to enable tmp.mount if we actually
     copied it to /etc. Don't try to enable a generated unit. (LP: #1545707)
   * debian/tests/boot-and-services: Increase timeouts of test_bash_crash from
     5 to 10 seconds, and sync the journal after every iteration.
   * debian/extra/checkout-upstream: Try again after one minute if git checkout
     fails, to avoid failures from transient network errors.
   * debian/tests/systemd-fsckd: Use grub.d/50-cloudimg-settings.cfg as a
     template for generating our custom one instead of 90-autopkgtest.cfg. The
     latter does not exist on non-x86 architectures and is not relevant for
     this test.
   * debian/tests/boot-and-services: Skip journal test for test_bash_crash when
     running against upstream, as this currently fails most of the time. To be
     investigated.
   * debian/tests/networkd: Skip test_coldplug_dhcp_ip6 when running against
     upstream, as this is brittle there. To be investigated.
   * debian/tests/bootchart: Skip test if bootchart is not available or
     testing in upstream mode. bootchart got removed from master and will be
     moved to a separate repository.
   * debian/tests/boot-and-services: Show verbose journal output on failure in
     nspawn test, and sync journal before.
   * Move systemd-coredump socket and service into systemd-coredump binary
     package.
   * Revert changing the default core dump ulimit and core_pattern. This
     completely breaks core dumps without systemd-coredump. It's also
     contradicting core(8). (Closes: #815020)
   * Fix addresses for type "sit" tunnels. (Closes: #816132)
   * networkd: Go back to letting the kernel handle IPv6 router advertisements,
     as networkd's own currently has too many regressions. Thanks to Stefan
     Lippers-Hollmann for investigating this! (Closes: #814566,
     #814667, #815586, #815884, #815793)
Checksums-Sha1:
 156fa5d375e0c8b78236e63bab76b9ac5d27431d 4073 systemd_229-2.dsc
 710d9893f3be794af273690d23278018c1cd4a24 120360 systemd_229-2.debian.tar.xz
 4a514b66b399768c86e558af3dfbc4aa2b0d6253 85468 libnss-myhostname_229-2_amd64.deb
 2a02acf3325462c1708092416a668ce095c0dede 165672 libnss-mymachines_229-2_amd64.deb
 34f58c3a13b468af8803661450a427520b8dc33c 164916 libnss-resolve_229-2_amd64.deb
 7e289fa3cb5b743eb49ccdf5d7a62fb152a0f0ec 167540 libpam-systemd_229-2_amd64.deb
 e11a01a97153d5b6da82327cd8bdd96ea7f1f5ed 211292 libsystemd-dev_229-2_amd64.deb
 0aee070430db6b8f87920352e9117aa06d376bb9 254720 libsystemd0_229-2_amd64.deb
 f4138aba406223ade1ad6af832b81bff6fdd27cc 71598 libudev-dev_229-2_amd64.deb
 24a4149667595df98aa618a9474e02741d30b368 47798 libudev1-udeb_229-2_amd64.udeb
 8f3f64e84bafa88d09952c5159f9b81a8e9f84dc 104192 libudev1_229-2_amd64.deb
 0ea74f0b64e0ece3104e2e7d47ec4d6961e03d6a 701838 systemd-container_229-2_amd64.deb
 856d3b5bbdd54786258a5bb1d7e9eb9737fd09f2 159860 systemd-coredump_229-2_amd64.deb
 c05f3eacb6b428bb48348d36ea0f24fb8be1fd4f 30101104 systemd-dbg_229-2_amd64.deb
 8154fe7231f77332bf6f27da81709639e0718acf 315850 systemd-journal-remote_229-2_amd64.deb
 b66616a95d942dae475835f577eec0de120c86e6 61742 systemd-sysv_229-2_amd64.deb
 31f95d47c325286a304e58c72f4591b058eba2e7 3654292 systemd_229-2_amd64.deb
 eaeb339dbdc48e27a9fe4a0a23470a0b402e5602 266906 udev-udeb_229-2_amd64.udeb
 9bc0f1b3fb361f98eaac88a2df1ac06797c07b17 1039278 udev_229-2_amd64.deb
Checksums-Sha256:
 08ac5b74baa76f8724d3ef587dd4b6a9f5c6a5020ec30dffb384a17953542ae3 4073 systemd_229-2.dsc
 a0b7f59fc44d392ab68b551c4eacd9ddb6299f95f1f23457b4dcdc7b46d2a982 120360 systemd_229-2.debian.tar.xz
 ab557b54ec9855420dddb55cf3d32fb0c7a8f7232a737f5bb1d9a1df482fc4ad 85468 libnss-myhostname_229-2_amd64.deb
 e5023006b6e51d22ba8e6c2c9c7e946646d953e2ddeee66255176684fb08b621 165672 libnss-mymachines_229-2_amd64.deb
 ef37d07be01e3cdd8611ab246526153886168b61005fe5eaa0286e6d529afd90 164916 libnss-resolve_229-2_amd64.deb
 878b549fe21459845d118792d3dcee75247db593d3f26c062850e399a0bf84ed 167540 libpam-systemd_229-2_amd64.deb
 48740d20af0fce47dc56a699c68999f9c152ffec2ff4f3153729f0d4344bb0bb 211292 libsystemd-dev_229-2_amd64.deb
 58d3b402807bf83e2788d938c87fd36ce0a9f7e0b3cc9ece806366fb18618dd2 254720 libsystemd0_229-2_amd64.deb
 f5126ce29963d5bd0ab07fdc0142898efacc1eee726cd21e9b22484b8dd8f3a1 71598 libudev-dev_229-2_amd64.deb
 37453c3db05a4894ae992195374bd555c8761e766f29b9ae41dc11c713e9eff9 47798 libudev1-udeb_229-2_amd64.udeb
 00ae505cf1d03b08a1fb0a855eaea941f577420ac1729ef9f968f23e685a754c 104192 libudev1_229-2_amd64.deb
 9d42e205f855fac18fc7404ac3389cbfbb23c6f5c8b21296b156228860175ecf 701838 systemd-container_229-2_amd64.deb
 55f7de73e9e138075965672b0efefcb241c57d9477284bee2fd28d4a3ffbe13a 159860 systemd-coredump_229-2_amd64.deb
 09c3571913d93e676d2442d5fe967f1d762ffb75a39ea936ba4497a7466e23f6 30101104 systemd-dbg_229-2_amd64.deb
 767329c159948bf1b66432b654748d90a7ba8189721ef791f6ee9d8da9806f56 315850 systemd-journal-remote_229-2_amd64.deb
 f9f931e8607392e968c61c8433edf23a9535e92cab84caa176e82e65662b6bc4 61742 systemd-sysv_229-2_amd64.deb
 17a0703ae4859dd9ed74c0b65753b4e714cec2e08ae8c4f42dfe9bf54d8d96e3 3654292 systemd_229-2_amd64.deb
 1042cf1cdf67ccff03c2009d94e230344f5e31561ec3d4daa92be9ff353a563d 266906 udev-udeb_229-2_amd64.udeb
 fecee4479dfcf81d4657bff51fba2ab0f0d5f76020e8ad5577faeb663983d9b2 1039278 udev_229-2_amd64.deb
Files:
 a2af5a1ab48dc08cf0d46fd377b11700 4073 admin optional systemd_229-2.dsc
 da34adb504cc69ca1c00265fb85cdb91 120360 admin optional systemd_229-2.debian.tar.xz
 7a0aedda643c8c495f0dfef7b180426c 85468 admin extra libnss-myhostname_229-2_amd64.deb
 084324f2bb552d1d8d6dbd51b30a85e3 165672 admin extra libnss-mymachines_229-2_amd64.deb
 73865f1584f7f04637cd2a1a14712703 164916 admin extra libnss-resolve_229-2_amd64.deb
 0d21cebf41341ca0cfea94738ac71188 167540 admin optional libpam-systemd_229-2_amd64.deb
 7123ee343f67ace0e7833855671c437c 211292 libdevel optional libsystemd-dev_229-2_amd64.deb
 8d5d495b19b7a566188f2ba02f6ea0e0 254720 libs optional libsystemd0_229-2_amd64.deb
 75a443208963585a60b40f7ef3c4ee2c 71598 libdevel optional libudev-dev_229-2_amd64.deb
 46e8d2461bf681fca506ff291c7d470f 47798 debian-installer optional libudev1-udeb_229-2_amd64.udeb
 678c7c4e80bdda5afb5fbda1d71b1b0b 104192 libs important libudev1_229-2_amd64.deb
 0730ebcfc900fb78ca0f2c5313b4d6c5 701838 admin optional systemd-container_229-2_amd64.deb
 4b065b2dd1afc5b2a82d9fc315c482d4 159860 admin optional systemd-coredump_229-2_amd64.deb
 c3be434bba6294a9804278e75aa0d828 30101104 debug extra systemd-dbg_229-2_amd64.deb
 c89236988e34098d4f64a521e007c550 315850 admin optional systemd-journal-remote_229-2_amd64.deb
 66a6af89c2bd9a096854f118940c9b4d 61742 admin important systemd-sysv_229-2_amd64.deb
 9afccd1cacd1b1c25ee625110c374631 3654292 admin important systemd_229-2_amd64.deb
 6328606aa7865e9175608ba0c16a607d 266906 debian-installer optional udev-udeb_229-2_amd64.udeb
 25188872614e08643a88119c4b9884e8 1039278 admin important udev_229-2_amd64.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW02o1AAoJENFO8V2v4RNHYJ8QAIF7s1agXJiLCH3ed41GaNGg
DIWj+zYiFYE4vIKnrKcHkCfzTB5szniJ9WgfDgiPrqjkpFhDNVjkDtzJ14bIIJt5
NG0xQAKo6AbV1MP0vAp39uGC3Ic8Z6MSR2NUfV9/bpMDgW2kn7Mh/Q+SG5HIPSNw
LvNnCR8fG9a6EAeSemjcRn7x05kI4GUh+TIFO1+Y4yJqjm8V1el76mtQl1xLgBz2
jjyZvBJ/s+imi5YhA7Ljk+w+59Slohd15gYFb41s7eqmlJQkOibMpMKA7R72Q3B1
QtNBgKOVAqDjzxE0VGJeYqm4sC+fqmcvloAAS23O/9s2zi8svdUrpcHQw+WmMrJt
uuJbbSEyUFxGtFtPjFjoeAKiSYNYA2ZIHIJqHa8eLyJ9dA+JrW71n7nTIpN1irNi
FXLEWATN61ZkIlLrM3wIKJ/gIQrX+UPvqMQ1Kyd7xilWmjGLrQaHxCsycLMe6x5q
EqOaofjdhuZP4vrrkffwINaEA3vF9RcFqxOYNYeNoyn3708EDRjc4HxVP6dPEELM
73nnkwIN2ZOSTNgGeKc7UQREMkw1a6o08fuEag4FuCiiyT+eGJESikKpOZ6Sz2B4
/I0ya+1svgGdg/kPT44AmnFKsWRmYOU5g5u4I4WgaRV6fsdUUf7SUMFodCJSoCHo
Y0zQipuV8XlZXi5nXdSI
=c5dP
-----END PGP SIGNATURE-----

Message #23 received at 815884@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Marc Haber <mh+debian-packages@zugschlus.de>, 815884@bugs.debian.org

Subject: Re: Bug#815884: does not retry IPv6 router solicitations

Date: Wed, 6 Jul 2016 10:50:53 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #34 received at 815884@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Martin Pitt <mpitt@debian.org>

Cc: 815884@bugs.debian.org

Subject: Re: Bug#815884: does not retry IPv6 router solicitations

Date: Wed, 6 Jul 2016 11:50:45 +0200

On Wed, Jul 06, 2016 at 10:50:53AM +0200, Martin Pitt wrote:
> 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?

I can easily try that without too much pain, yes. I hope I'll get
around to doing so tonight.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Message #41 received at 815884@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Martin Pitt <mpitt@debian.org>

Cc: 815884@bugs.debian.org

Subject: Re: Bug#815884: does not retry IPv6 router solicitations

Date: Sat, 16 Jul 2016 13:33:41 +0200

On Wed, Jul 06, 2016 at 10:50:53AM +0200, Martin Pitt wrote:
> networkd actually tries a RS three times, but from then on only
> regularly retries DHCPv6 soliciations, no router solicitations:

I can confirm this. So this bug can be closed.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Message #46 received at 815884-done@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Marc Haber <mh+debian-packages@zugschlus.de>, 815884-done@bugs.debian.org

Subject: Re: Bug#815884: does not retry IPv6 router solicitations

Date: Tue, 26 Jul 2016 08:50:53 +0200

Hello Marc,

Marc Haber [2016-07-16 13:33 +0200]:
> On Wed, Jul 06, 2016 at 10:50:53AM +0200, Martin Pitt wrote:
> > networkd actually tries a RS three times, but from then on only
> > regularly retries DHCPv6 soliciations, no router solicitations:
> 
> I can confirm this. So this bug can be closed.

Ack, closing. So I understand this as "the kernel does not
indefinitiely retry either, so it's not a behaviour change"?

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #47 received at 815884-done@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Martin Pitt <mpitt@debian.org>

Cc: 815884-done@bugs.debian.org

Subject: Re: Bug#815884: does not retry IPv6 router solicitations

Date: Tue, 26 Jul 2016 10:13:49 +0200

On Tue, Jul 26, 2016 at 08:50:53AM +0200, Martin Pitt wrote:
> Marc Haber [2016-07-16 13:33 +0200]:
> > On Wed, Jul 06, 2016 at 10:50:53AM +0200, Martin Pitt wrote:
> > > networkd actually tries a RS three times, but from then on only
> > > regularly retries DHCPv6 soliciations, no router solicitations:
> > 
> > I can confirm this. So this bug can be closed.
> 
> Ack, closing. So I understand this as "the kernel does not
> indefinitiely retry either, so it's not a behaviour change"?

Yes. Just trying once is not enough.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Send a report that this bug log contains spam.