Your message dated Fri, 23 Mar 2018 17:24:02 +0100
with message-id <d224da26-a84c-6aa7-2843-53a9aac69...@debian.org>
and subject line Re: Bug#831414: systemd: learns IPv6 prefix from its own RAs
and configures IP address on wrong interface
has caused the Debian Bug report #831414,
regarding systemd: learns IPv6 prefix from its own RAs and configures IP
address on wrong interface
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
831414: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831414
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 230-5pitti1
Severity: minor
Tags: ipv6
Hi,
I am filing this as severity minor because this bug is in a version
that is not officially in Debian. I am filing it nevertheless because
systemd with this IPv6 user space code active should not be in Debian.
If this were an official version, this would be an important bug, with
the potential for "serious" at maintainer discretion.
While following up Martin's requests for #815793 and #815884, I have
found new misbehsvior regarding IPv6.
Given a host that also acts as a router, with the following network
setup:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
link/ether 54:04:a6:82:21:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.182.250/32 brd 192.168.182.250 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.182.29/24 brd 192.168.182.255 scope global dynamic eth0
valid_lft 12650sec preferred_lft 12650sec
inet6 2001:db8:0:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr
noprefixroute dynamic
valid_lft 86309sec preferred_lft 14309sec
inet6 2001:db8:0:3282::1d:250/128 scope global
valid_lft forever preferred_lft forever
inet6 2001:db8:0:3282::1d:100/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5604:a6ff:fe82:2100/64 scope link
valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group
default qlen 1000
link/ether c6:f4:98:dc:5e:21 brd ff:ff:ff:ff:ff:ff
inet 192.168.29.254/24 brd 192.168.29.255 scope global br0
valid_lft forever preferred_lft forever
inet6 2001:db8:0:328d::1d:153/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:db8:0:328d::1d:100/64 scope global
valid_lft forever preferred_lft forever
inet6 fec0:0:0:ffff::3/128 scope site
valid_lft forever preferred_lft forever
inet6 fec0:0:0:ffff::2/128 scope site
valid_lft forever preferred_lft forever
inet6 fec0:0:0:ffff::1/128 scope site
valid_lft forever preferred_lft forever
inet6 fe80::c4f4:98ff:fedc:5e21/64 scope link
valid_lft forever preferred_lft forever
On br0, there is a radvd, advertising a prefix on br0:
interface br0 {
AdvSendAdvert on;
MinRtrAdvInterval 600;
MaxRtrAdvInterval 1200;
prefix 2001:db8:0:328d::/64 {
DeprecatePrefix on;
};
RDNSS 2001:db8:0:328d::1d:153 {
AdvRDNSSLifetime 1200;
};
};
When the radvd is started, the local host seems to learn the prefix
from the locally running radvd and _configures_ _it_ _on_ _eth0_,
which is plain wrong:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP gr
oup default qlen 1000
link/ether 54:04:a6:82:21:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.182.250/32 brd 192.168.182.250 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.182.29/24 brd 192.168.182.255 scope global dynamic eth0
valid_lft 12530sec preferred_lft 12530sec
inet6 2001:db8:0:328d:5604:a6ff:fe82:2100/64 scope global mngtmpaddr
noprefixroute dynamic
valid_lft 86390sec preferred_lft 14390sec
inet6 2001:db8:0:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr
noprefixroute dynamic
valid_lft 86189sec preferred_lft 14189sec
inet6 2001:db8:0:3282::1d:250/128 scope global
valid_lft forever preferred_lft forever
inet6 2001:db8:0:3282::1d:100/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5604:a6ff:fe82:2100/64 scope link
valid_lft forever preferred_lft forever
It also learns a default route pointing to its own link local IP
address on br0:
[2/502]mh@fan:~$ ip -6 r
2001:db8:0:3282::1d:250 dev eth0 proto kernel metric 256 pref medium
2001:db8:0:3282::/64 dev eth0 proto kernel metric 256 pref medium
2001:db8:0:3282::/64 dev eth0 proto ra metric 1024 pref medium
2001:db8:0:328d::/64 dev br0 proto kernel metric 256 pref medium
2001:db8:0:328d::/64 dev eth0 proto ra metric 1024 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev dummy0 proto kernel metric 256 pref medium
fe80::/64 dev br0 proto kernel metric 256 pref medium
fe80::/64 dev vnet0 proto kernel metric 256 pref medium
fec0:0:0:ffff::1 dev br0 proto kernel metric 256 pref medium
fec0:0:0:ffff::2 dev br0 proto kernel metric 256 pref medium
fec0:0:0:ffff::3 dev br0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 proto ra metric 1024 hoplimit 64 pref high
default via fe80::c4f4:98ff:fedc:5e21 dev eth0 proto ra metric 1024 pref
medium
[3/503]mh@fan:~$
which is also plain wrong.
While it is proably debateable whether a host is supposed to learn an
IPv6 prefix from a locally running radvd (I can't quote the relevant
parts of the standard right now), it is plain wrong to configure the
newly learned IP address on a totally different interface and to
configure a default route pointing to itself.
I am lucky that my host is still networking in the first place. It
shouldn't with the second default route in place.
Greetings
Marc
-- Package-specific info:
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.6.4-zgws1 (SMP w/6 CPU cores)
Locale: LANG=en_DK.utf8, LC_CTYPE=en_DK.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii adduser 3.115
ii libacl1 2.2.52-3
ii libapparmor1 2.10.95-4
ii libaudit1 1:2.6.3-1
ii libblkid1 2.28-5
ii libc6 2.23-1
ii libcap2 1:2.25-1
ii libcap2-bin 1:2.25-1
ii libcryptsetup4 2:1.7.0-2
ii libgcrypt20 1.7.1-2
ii libgpg-error0 1.23-1
ii libidn11 1.32-3.1
ii libkmod2 22-1.1
ii liblzma5 5.1.1alpha+20120614-2.1
ii libmount1 2.28-5
ii libpam0g 1.1.8-3.3
ii libseccomp2 2.3.1-2
ii libselinux1 2.5-3
ii libsystemd0 230-5pitti1
ii mount 2.28-5
ii util-linux 2.28-5
Versions of packages systemd recommends:
ii dbus 1.10.8-1
ii libpam-systemd 230-5pitti1
Versions of packages systemd suggests:
ii policykit-1 0.105-15
pn systemd-container <none>
pn systemd-ui <none>
Versions of packages systemd is related to:
ii udev 230-5pitti1
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 234-1
On Mon, 16 Oct 2017 19:01:14 +0200 Michael Biebl <bi...@debian.org> wrote:
> Closing the bug report for that version then.
This time for real...
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
