Bug 110721

Summary:	IPv6 Autoconfiguration configures wrong interface.
Product:	Networking	Reporter:	Stefan J. Betz (info)
Component:	IPV6	Assignee:	Hideaki YOSHIFUJI (yoshfuji)
Status:	NEW ---
Severity:	normal	CC:	flokli, hannes, info, martin, mh+kernel-bugzilla, szg00000, teg
Priority:	P1
Hardware:	Intel
OS:	Linux
Kernel Version:	4.3.3	Subsystem:
Regression:	No	Bisected commit-id:

Description Stefan J. Betz 2016-01-12 20:39:48 UTC

I have two Interfaces in my System:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) => enp2s0
05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection => enp5s0

enp2s0 is connected to my DSL Router, which provides IPv6 Router Advertisements from my Provider.

But enp2s0 never gets an IPv6 Address (except fe80…), instead enp5s0 (an Interfaces without RAs on the line, tcpdump validated) gets an public usable ipv6 address. Because enp5s0 has no connection to my WAN, this address is unusable.

enp5s0 is member of a bridge calles br0

Disabling accept_ra, forwarding and autoconf sysctl Settings on br0, enp2s0 and enp5s0 doesnt change anything. Disabling IPv6 complete (disable_ipv6 sysctl) on enp2s0 solves the Problem (as a workaround).

tl;dr: enp2s0 gets router advertisments and is connect to my dsl router, but enp5s0 (part ob an Bridge br0) gets configured for ipv6, without connection to my dsl router.

Any ideas?

Comment 1 Martin Weinelt 2016-01-31 01:54:16 UTC

Can confirm that issue with a slightly different setup.

Tested on:
 - 4.1.16-1
 - 4.3.3-3
both affected

I have a VPN setup that runs batman-adv in a bridge with en1, where the radv arrive. The other phys. if (en0) gets the ip6 addresses, even though there are no radv packets on that interface (confirmed by tcpdump, ip6tables logging)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: en0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:25:90:xx:xx:00 brd ff:ff:ff:ff:ff:ff
3: en1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master xxx-bat0 state UP mode DEFAULT group default qlen 1000
    link/ether 00:25:90:xx:xx:01 brd ff:ff:ff:ff:ff:ff
16: foo-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc noqueue master xxx-bat0 state UNKNOWN mode DEFAULT group default qlen 500
    link/ether 56:a3:b3:8b:aa:e4 brd ff:ff:ff:ff:ff:ff
17: foo-bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master xxx-br state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 2a:a9:cb:dd:79:4e brd ff:ff:ff:ff:ff:ff
18: foo-br: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 2a:a9:cb:dd:79:4e brd ff:ff:ff:ff:ff:ff

# brctl show
bridge name	bridge id		STP enabled	interfaces
foo-br		8000.2aa9cbdd794e	no		foo-bat0

# batctl -m xxx-bat0 if
en1: active                                   
foo-vpn: active

radv on `foo-bat0` and `foo-br` gets no ip6 addresses
- accept_ra, autoconfig = 0
- forwarding = 0

en0 gets ip6 adresses and routes from those radv, even though there are _no_ matching radv on that if.
- accept_ra, autoconfig = 1
- forwarding = 0

Comment 2 Martin Weinelt 2016-01-31 01:55:13 UTC

Mixed up the anonymization, `xxx-*` equals `foo-*`, sorry!

Comment 3 hannes 2016-02-23 09:03:23 UTC

Can you have a look at report https://bugzilla.kernel.org/show_bug.cgi?id=112751 and check if that applies to you, too? I couldn't reproduce your problem.

Comment 4 Marc Haber 2016-02-23 10:45:42 UTC

What system are you seeing this issue on? One with systemd 229, maybe? Starting with this version of systemd?

Comment 5 Martin Weinelt 2016-02-23 17:21:49 UTC

For me this happens on an Archlinux with Kernel 4.1.17-1-lts with systemd 228-4.

Comment 6 Marc Haber 2016-02-23 17:58:01 UTC

Recent systemd versions (I always thought this started with 229) process incoming router announcements themselves. Can you try stracing the systemd or the networkd process to see whether it is actually acting on the route announcement?

Too bad that systemd upstream doesn't seem to publish a changelog.

Comment 7 hannes 2016-02-23 18:03:41 UTC

Tom, could you have a look at this issue? Any idea if systemd could be the issue here?

Thanks,
Hannes

Comment 8 Florian Klink 2016-04-13 11:27:14 UTC

@Hannes: I'm pretty sure systemd is the issue.

In one setup here (systemd 229), everything worked fine, until I added a dummy interface, and configured a static ipv6 address via systemd-networkd on it.

Suddenly ip addresses from eth0 started to appear on the dummy interface.

Seems like systemd is messing up which interface the RA came from.