Hi,
I have the same problem on my TP-Link Archer C2600 (v1.1) running the latest LEDE snapshot (r2535-720b992).
I was able to reproduce it on a very simple setup by following those steps :
-
start from a fresh install of LEDE with default settings (http://downloads.lede-project.org/snapshots/targets/ipq806x/generic/lede-ipq806x-C2600-squashfs-factory.bin installed using the TFTP method).
install the following packages: ip-full libpcap tcpdump
-
configure a STATIC IPv6 address on the WAN port: edit /etc/config/network as follows and reboot:
config interface 'wan'
option ifname 'eth0'
option proto 'static'
option ip6addr '2001:470:cbf0:40::2/125'
option ip6gw '2001:470:cbf0:40::1'
-
configure a Linux host as follows and connect its eth1 interface to the WAN port of the router:
ip -6 addr add 2001:470:cbf0:40::1/125 dev eth1
-
from the Linux host, try to ping the router IP6 address
root@linux:~# ping6 2001:470:cbf0:40::2
PING 2001:470:cbf0:40::2(2001:470:cbf0:40::2) 56 data bytes
From 2001:470:cbf0:40::1 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:470:cbf0:40::1 icmp_seq=2 Destination unreachable: Address unreachable
From 2001:470:cbf0:40::1 icmp_seq=3 Destination unreachable: Address unreachable
^C
--- 2001:470:cbf0:40::2 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3005ms
root@linux:~# ip -6 neigh ls dev eth1
2001:470:cbf0:40::2 FAILED
capture on the Linux host:
root@linux:~# tcpdump -e -i eth1 -n -p
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
10:48:11.150434 00:0c:29:0c:1b:73 > 33:33:ff:00:00:02, ethertype IPv6 (0x86dd), length 86: 2001:470:cbf0:40::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:470:cbf0:40::2, length 32
10:48:12.149863 00:0c:29:0c:1b:73 > 33:33:ff:00:00:02, ethertype IPv6 (0x86dd), length 86: 2001:470:cbf0:40::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:470:cbf0:40::2, length 32
10:48:13.150106 00:0c:29:0c:1b:73 > 33:33:ff:00:00:02, ethertype IPv6 (0x86dd), length 86: 2001:470:cbf0:40::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:470:cbf0:40::2, length 32
10:48:15.165910 00:0c:29:0c:1b:73 > 33:33:ff:00:00:02, ethertype IPv6 (0x86dd), length 86: 2001:470:cbf0:40::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:470:cbf0:40::2, length 32
10:48:16.165988 00:0c:29:0c:1b:73 > 33:33:ff:00:00:02, ethertype IPv6 (0x86dd), length 86: 2001:470:cbf0:40::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:470:cbf0:40::2, length 32
10:48:17.166054 00:0c:29:0c:1b:73 > 33:33:ff:00:00:02, ethertype IPv6 (0x86dd), length 86: 2001:470:cbf0:40::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:470:cbf0:40::2, length 32
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
capture on the router:
root@lede:~# tcpdump -e -i eth0 -n -p ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
It appears that the LEDE router don't see the ND requests from the Linux host. Consequently, it doesn't answer them and ND fails.
- put the WAN interface in promisc mode and do the same test again:
root@lede:~# ifconfig eth0 promisc
root@linux:~# ping6 2001:470:cbf0:40::2
PING 2001:470:cbf0:40::2(2001:470:cbf0:40::2) 56 data bytes
64 bytes from 2001:470:cbf0:40::2: icmp_seq=1 ttl=64 time=4.56 ms
^C
--- 2001:470:cbf0:40::2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.568/4.568/4.568/0.000 ms
root@linux:~# ip -6 neigh ls dev eth1
2001:470:cbf0:40::2 lladdr a4:2b:b0:fa:b1:1b router STALE
root@linux:~# tcpdump -e -i eth1 -n -p
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
10:51:20.348986 00:0c:29:0c:1b:73 > 33:33:ff:00:00:02, ethertype IPv6 (0x86dd), length 86: 2001:470:cbf0:40::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:470:cbf0:40::2, length 32
10:51:20.350073 a4:2b:b0:fa:b1:1b > 00:0c:29:0c:1b:73, ethertype IPv6 (0x86dd), length 86: 2001:470:cbf0:40::2 > 2001:470:cbf0:40::1: ICMP6, neighbor advertisement, tgt is 2001:470:cbf0:40::2, length 32
10:51:20.350101 00:0c:29:0c:1b:73 > a4:2b:b0:fa:b1:1b, ethertype IPv6 (0x86dd), length 118: 2001:470:cbf0:40::1 > 2001:470:cbf0:40::2: ICMP6, echo request, seq 1, length 64
10:51:20.353542 a4:2b:b0:fa:b1:1b > 00:0c:29:0c:1b:73, ethertype IPv6 (0x86dd), length 118: 2001:470:cbf0:40::2 > 2001:470:cbf0:40::1: ICMP6, echo reply, seq 1, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
root@lede:~# tcpdump -i eth0 -n -p ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:01:51.038208 IP6 2001:470:cbf0:40::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:470:cbf0:40::2, length 32
22:01:51.038551 IP6 2001:470:cbf0:40::2 > 2001:470:cbf0:40::1: ICMP6, neighbor advertisement, tgt is 2001:470:cbf0:40::2, length 32
22:01:51.039306 IP6 2001:470:cbf0:40::1 > 2001:470:cbf0:40::2: ICMP6, echo request, seq 1, length 64
22:01:51.042068 IP6 2001:470:cbf0:40::2 > 2001:470:cbf0:40::1: ICMP6, echo reply, seq 1, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
With the WAN interface in promiscuous mode, the router correctly receives and process the ND requests and the connectivity is OK.
- another workaround is to put the WAN port inside a bridge
edit /etc/config/network as follows and reboot:
config interface 'wan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ip6addr '2001:470:cbf0:40::2/125'
option ip6gw '2001:470:cbf0:40::1'
flush the ND cache on the Linux host:
root@linux:~# ip -6 neigh flush dev eth1
do the same tests again:
root@linux:~# ping6 2001:470:cbf0:40::2
PING 2001:470:cbf0:40::2(2001:470:cbf0:40::2) 56 data bytes
64 bytes from 2001:470:cbf0:40::2: icmp_seq=1 ttl=64 time=2.16 ms
^C
--- 2001:470:cbf0:40::2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.165/2.165/2.165/0.000 ms
root@linux:~# ip -6 neigh ls dev eth1
2001:470:cbf0:40::2 dev eth1 lladdr a4:2b:b0:fa:b1:1b router STALE
root@linux:~# tcpdump -e -i eth1 -n -p
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
10:59:49.627403 00:0c:29:0c:1b:73 > 33:33:ff:00:00:02, ethertype IPv6 (0x86dd), length 86: 2001:470:cbf0:40::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:470:cbf0:40::2, length 32
10:59:49.628374 a4:2b:b0:fa:b1:1b > 00:0c:29:0c:1b:73, ethertype IPv6 (0x86dd), length 86: 2001:470:cbf0:40::2 > 2001:470:cbf0:40::1: ICMP6, neighbor advertisement, tgt is 2001:470:cbf0:40::2, length 32
10:59:49.628403 00:0c:29:0c:1b:73 > a4:2b:b0:fa:b1:1b, ethertype IPv6 (0x86dd), length 118: 2001:470:cbf0:40::1 > 2001:470:cbf0:40::2: ICMP6, echo request, seq 1, length 64
10:59:49.629551 a4:2b:b0:fa:b1:1b > 00:0c:29:0c:1b:73, ethertype IPv6 (0x86dd), length 118: 2001:470:cbf0:40::2 > 2001:470:cbf0:40::1: ICMP6, echo reply, seq 1, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
root@lede:~# tcpdump -i eth0 -n -p ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-wan, link-type EN10MB (Ethernet), capture size 262144 bytes
22:09:32.649184 IP6 2001:470:cbf0:40::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:470:cbf0:40::2, length 32
22:09:32.649476 IP6 2001:470:cbf0:40::2 > 2001:470:cbf0:40::1: ICMP6, neighbor advertisement, tgt is 2001:470:cbf0:40::2, length 32
22:09:32.650198 IP6 2001:470:cbf0:40::1 > 2001:470:cbf0:40::2: ICMP6, echo request, seq 1, length 64
22:09:32.650580 IP6 2001:470:cbf0:40::2 > 2001:470:cbf0:40::1: ICMP6, echo reply, seq 1, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
-
another interesting point is that I was able to reproduce the same exact behavior on the LAN interface as well as on a WLAN SSID.
It looks more like a kernel bug or misconfiguration than a NIC driver issue.
In addition, I don't know what router model dissent1 is using but odds are that it is not the same as mine.
-
Another issue I've observed on my client networks (both wired and wireless) is that the router don't always respond to router solicitation.
With the linux host configured as a client:
root@linux:~# echo 1 > /proc/sys/net/ipv6/conf/eth1/autoconf
root@linux:~# echo 1 > /proc/sys/net/ipv6/conf/eth1/accept_ra
root@linux:~# echo 0 > /proc/sys/net/ipv6/conf/eth1/forwarding
And the LEDE router is configured with a prefix to distribute to its clients (2001:470:cbf0:43::/64).
root@linux:~# tcpdump -e -i eth1 -n -p ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
12:42:00.080308 00:0c:29:0c:1b:73 > 33:33:ff:0c:1b:73, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff0c:1b73: ICMP6, neighbor solicitation, who has fe80::20c:29ff:fe0c:1b73, length 24
12:42:01.082364 00:0c:29:0c:1b:73 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: fe80::20c:29ff:fe0c:1b73 > ff02::2: ICMP6, router solicitation, length 8
12:42:04.900391 00:0c:29:0c:1b:73 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: fe80::20c:29ff:fe0c:1b73 > ff02::2: ICMP6, router solicitation, length 8
12:42:08.899554 00:0c:29:0c:1b:73 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: fe80::20c:29ff:fe0c:1b73 > ff02::2: ICMP6, router solicitation, length 8
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
root@lede:~# tcpdump -e -i br-lan -n -p ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
We can see that the RD requests sent to multicast address ff02::2 are not received by the LEDE router. Some ND request are impacted too.
This happens even if the interface is part of a bridge. The only workaround I've found is to put the bridge in promiscuous mode.
The value of /sys/devices/virtual/net/br-lan/bridge/multicast_snooping doesn't change the observed behavior.
All physical and bridge interfaces have the MULTICAST flag set in ifconfig.
The only thing that seems to make a difference is putting the bridge interface in promisc mode.
root@lede:~# ifconfig br-lan promisc
In which case connectivity is OK.
root@lede:~# tcpdump -e -i br-lan -n -p ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-wired, link-type EN10MB (Ethernet), capture size 262144 bytes
13:02:34.903106 00:0c:29:0c:1b:73 > 33:33:ff:0c:1b:73, ethertype IPv6 (0x86dd), length 86: :: > ff02::1:ff0c:1b73: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff0c:1b73, length 24
13:02:34.988576 00:0c:29:0c:1b:73 > 33:33:ff:0c:1b:73, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff0c:1b73: ICMP6, neighbor solicitation, who has fe80::20c:29ff:fe0c:1b73, length 24
13:02:35.994191 00:0c:29:0c:1b:73 > 33:33:00:00:00:fb, ethertype IPv6 (0x86dd), length 86: fe80::20c:29ff:fe0c:1b73 > ff02::fb: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::fb, length 24
13:02:35.996232 00:0c:29:0c:1b:73 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 62: fe80::20c:29ff:fe0c:1b73 > ff02::2: ICMP6, router solicitation, length 8
13:02:36.000041 a4:2b:b0:fa:b1:1a > 33:33:ff:0c:1b:73, ethertype IPv6 (0x86dd), length 86: fe80::a62b:b0ff:fefa:b11a > ff02::1:ff0c:1b73: ICMP6, neighbor solicitation, who has fe80::20c:29ff:fe0c:1b73, length 32
13:02:36.001423 00:0c:29:0c:1b:73 > a4:2b:b0:fa:b1:1a, ethertype IPv6 (0x86dd), length 86: fe80::20c:29ff:fe0c:1b73 > fe80::a62b:b0ff:fefa:b11a: ICMP6, neighbor advertisement, tgt is fe80::20c:29ff:fe0c:1b73, length 32
13:02:36.001667 a4:2b:b0:fa:b1:1a > 00:0c:29:0c:1b:73, ethertype IPv6 (0x86dd), length 182: fe80::a62b:b0ff:fefa:b11a > fe80::20c:29ff:fe0c:1b73: ICMP6, router advertisement, length 128
13:02:37.027944 00:0c:29:0c:1b:73 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 146: fe80::20c:29ff:fe0c:1b73.546 > ff02::1:2.547: dhcp6 solicit
13:02:37.029386 a4:2b:b0:fa:b1:1a > 00:0c:29:0c:1b:73, ethertype IPv6 (0x86dd), length 198: fe80::a62b:b0ff:fefa:b11a.547 > fe80::20c:29ff:fe0c:1b73.546: dhcp6 advertise
13:02:38.052541 00:0c:29:0c:1b:73 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 188: fe80::20c:29ff:fe0c:1b73.546 > ff02::1:2.547: dhcp6 request
13:02:38.054857 a4:2b:b0:fa:b1:1a > 00:0c:29:0c:1b:73, ethertype IPv6 (0x86dd), length 230: fe80::a62b:b0ff:fefa:b11a.547 > fe80::20c:29ff:fe0c:1b73.546: dhcp6 reply
13:02:38.479262 00:0c:29:0c:1b:73 > 33:33:ff:00:02:3e, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff00:23e: ICMP6, neighbor solicitation, who has 2001:470:cbf0:43::23e, length 24
13:02:38.742337 00:0c:29:0c:1b:73 > 33:33:ff:0c:1b:73, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff0c:1b73: ICMP6, neighbor solicitation, who has 2001:470:cbf0:43:20c:29ff:fe0c:1b73, length 24
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel
- And digging further
The multicast configuration on the LEDE router is correct, both the L2 multicast MAC address 33:33:00:00:00:02 and the L3 IPv6 address ff02::2, that are used to receive the RD requests, are displayed on the groups the br-lan interface has subscribed to.
root@lede:~# ip maddr show dev br-lan
6: br-wired
inet6 ff02::1:ff00:0 users 2
inet6 ff05::1:3
inet6 ff02::1:2
inet6 ff02::1:fffa:b11a
inet6 ff02::1:ff00:1
inet6 ff02::2 users 2
inet6 ff02::1
inet6 ff01::1
Also, removing all ip6tables and setting the default policies of all chains doesn't make any difference.
Switching the interface to allmulticast mode makes the router receive the traffic for the groups it has not subscribed to (for instance: ff02::16), but traffic to the ND and RD groups is still lost.
So far the only workaround I've found is to put all bridge interfaces in promisc mode, which is in my opinion not satisfactory because of security and performance implications.