Weird problem I faced with IPv6 with PD that provides my ISP: it works only if I set wan interface into promiscuous mode. The weird thing is that setting it into that mode for only 10 seconds is enough to make IPv6 work okay until next reboot. So I've made a startup script that switches this mode on for 10 seconds and then switches it off.
Any ideas what could be the reason for such behavior?
IPv6 configuration is left default.
can you run the following test please
The problem is that tcpdump itself turns promiscuous mode on so ipv6 starts working immediately and until the reboot. Bringing wan interface down and up with turned off promisc won't break ipv6, only reboot does.
Must say that ip addresses are assigned correctly, it's the connectivity to ipv6 sites that doesn't work.
connectivity from the router itself or from the clients on the lan side ... to the wan side
Okay upon wider investigation I've came across new circumstances.
It's better to start from the beginning. My ISP provides internet through GPON. GPON terminal is set as a transparent bridge and internet comes tagged with VLAN 3, so I set wan port of the router tagged with vid 3 (remember it while reading further).
The problem described in 1st post seems to be only the half of the problem that I have encountered and that has revealed itself first on IPv6. I'll explain.
When I first tried to enable IPv6 it couldn't assign any IPv6 address to a router and any LAN client until I enabled promiscuous mode -> after that addresses were assigned and I could access IPv6 sites normally.
Then after reboot the IPv6 addresses are still being assigned to a router and LAN clients but there were no connectivity from LAN clients to global IPv6 sites, the router itself could ping ipv6.google.com. If I enable wan promiscuous mode, then LAN clients are getting IPv6 connectivity with IPv6 sites normally.
Trying to reproduce the situation when there are no IPv6 addresses being assigned, I've changed wan interface MAC address to the one that has never been noticed on my link from the ISP side. It did the trick and it has led me to the situation when along with absent IPv6 address I couldn't get IPv4 address as well. And again setting wan to promiscuous mode to solves the problem. After the reboot I have ok connectivity with IPv4, assigned IPv6 addresses but no connectivity from LAN clients to global IPv6 sites, so the situation repeats.
Seems like there is some kind of a "handshake" goes when new MAC address gets online.
Because of different technology of assigning ip addresses in IPv4 (nat with just router getting ip from ISP that's already "handshaked") and IPv6 (when global address is assigned to all devices in LAN) only IPv6 is affected by the problem described in 1st post, when I have to enable promiscuous mode for the router to "handshake" assigned prefix for lan subnet.
I think that it has something to do with vlan tagging, that isp sends something untagged that gets dropped by the switch that is set for certain vlan, because before this test I has never had problems with getting IPv4 address. I assume this is because when I first set the router it has no vlan tagging on wan port and it has some time to handshake itself with ISP while sending lease requests (though not getting answers) and this "handshake" seem to be kept at ISP side for certain MAC address, so when I enable vlan tagging after that to get internet it gets ipv4 freely.
Sorry for such a long story, I've tried to describe all my findings.
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.
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.
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
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.
Mine is Netgear R7800, also an ipq806x device.
This problem is present in dd-wrt with kernel 3.18 as well.
Interesting. On my side, I'm not able to reproduce the problem on another router, an Archer C7 v1 (ar71xx), with the same revision.
The R7800 seems to use the same drivers than the C2600 (ipq806x-gmac-dwmac for wired interfaces and ath10k for WLAN). Could be a good point to start from.
I have the same problem of not receiving multicast packets. This is with an R7800 but is nothing to do with IPv6 in my case: I see the problem with avahi. Avahi can send multicast announcements on lan and wifi interfaces. However, it never sees any multicast queries on the lan (but it receives them fine on wifi).
Setting promiscuous mode on the interface means avahi receives the queries. Turning it off again means it avahi doesn't receive them any more.
I presume there has been no progress on tracking this down so far? Any good ideas?
Yes. Setting either promiscuous mode (promisc) or all multicast mode (allmulti) allows multicast reception. allmulti is the better option as it requires handling much less traffic, of course.
The same happened on a X86 machine with two Intel NICs. I'm running r3282-50efd403e6 on this box, and ndppd won't receive any NS for LAN subnet on the WAN interface, resulting in "Destination Unreachable" error when accessing subnet from outside. Setting either promisc or allmulti solves the issue.
Anybody know whether this is fixed in 19.07?
I just had exactly the same issue during my attempt to replace my ISP provided box (french Freebox Revolution, 10G-EPON fiber) with a NanoPI R4S router powered by OpenWrt.
my setup is based on:
map to allow `4rd{ encapsulation of IPv4 traffic into IPv6 paquets (this is requirement specific to french ISP 'Free' in 10G-EPON connectivity case)My openWrt config:
config interface 'wan6'
option ifname 'eth0.836'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'try'
option macaddr 'F4:CA:XX:XX:XX:XX'
option mtu '1700'
list dns '2001:4860:4860::8888' # google IPv6 DNS
option peerdns '0'
without promiscuous mode, I get no DHCPv6 lease from ISP & the following logs:
root@OpenWrt:~# logread
Sun Feb 21 18:28:57 2021 daemon.notice netifd: Interface 'wan6' is now down
Sun Feb 21 18:28:57 2021 daemon.notice netifd: Interface 'wan6' is disabled
Sun Feb 21 18:28:57 2021 kern.info kernel: [ 2489.045174] rk_gmac-dwmac fe300000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
Sun Feb 21 18:28:57 2021 kern.info kernel: [ 2489.058499] rk_gmac-dwmac fe300000.ethernet eth0: No Safety Features support found
Sun Feb 21 18:28:57 2021 kern.warn kernel: [ 2489.059196] rk_gmac-dwmac fe300000.ethernet eth0: PTP not supported by HW
Sun Feb 21 18:28:57 2021 kern.info kernel: [ 2489.059810] rk_gmac-dwmac fe300000.ethernet eth0: configuring for phy/rgmii link mode
Sun Feb 21 18:28:57 2021 daemon.notice netifd: Interface 'wan6' is enabled
Sun Feb 21 18:29:00 2021 kern.info kernel: [ 2492.464898] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Sun Feb 21 18:29:00 2021 kern.info kernel: [ 2492.465738] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sun Feb 21 18:29:00 2021 daemon.notice netifd: Network device 'eth0' link is up
Sun Feb 21 18:29:00 2021 daemon.notice netifd: VLAN 'eth0.836' link is up
Sun Feb 21 18:29:00 2021 daemon.notice netifd: Interface 'wan6' has link connectivity
Sun Feb 21 18:29:00 2021 daemon.notice netifd: Interface 'wan6' is setting up now
Sun Feb 21 18:29:00 2021 kern.info kernel: [ 2492.467137] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.836: link becomes ready
Then, a few secondes after I enable the promiscous mode on eth0 with ifconfig eth0 promisc, I get:
Sun Feb 21 21:16:33 2021 kern.info kernel: [ 103.205826] device eth0 entered promiscuous mode
Sun Feb 21 21:17:24 2021 daemon.notice netifd: Interface 'wan6' is now up
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: reading /tmp/resolv.conf.d/resolv.conf.auto
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using only locally-known addresses for domain test
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using only locally-known addresses for domain onion
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using only locally-known addresses for domain localhost
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using only locally-known addresses for domain local
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using only locally-known addresses for domain invalid
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using only locally-known addresses for domain bind
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using only locally-known addresses for domain lan
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using nameserver 8.8.8.8#53
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using nameserver 8.8.4.4#53
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using nameserver 9.9.9.9#53
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: using nameserver 2001:4860:4860::8888#53
Sun Feb 21 21:17:24 2021 daemon.notice netifd: Interface 'wan6_4' is setting up now
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: read /etc/hosts - 4 addresses
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: read /tmp/hosts/odhcpd - 0 addresses
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq[1833]: read /tmp/hosts/dhcp.cfg01411c - 20 addresses
Sun Feb 21 21:17:24 2021 daemon.info dnsmasq-dhcp[1833]: read /etc/ethers - 0 addresses
Sun Feb 21 21:17:24 2021 user.notice firewall: Reloading firewall due to ifup of wan6 (eth0.836)
Sun Feb 21 21:17:24 2021 daemon.debug dnsmasq[1833]: listening on map-wan6_4(#7): xxx.yyy.zzz.ttt port 53
Sun Feb 21 21:17:24 2021 daemon.debug dnsmasq[1833]: listening on map-wan6_4(#7): fe80::dc97:86ff:fexx:xxxx%map-wan6_4 port 53
Sun Feb 21 21:17:24 2021 daemon.notice netifd: Interface 'wan6_4' is now up
Sun Feb 21 21:17:24 2021 daemon.notice netifd: tunnel 'map-wan6_4' link is up
Sun Feb 21 21:17:24 2021 daemon.notice netifd: Network alias 'eth0.836' link is up
Sun Feb 21 21:17:24 2021 daemon.notice netifd: Interface 'wan6_4_' is enabled
Sun Feb 21 21:17:24 2021 daemon.notice netifd: Interface 'wan6_4_' is setting up now
Sun Feb 21 21:17:24 2021 daemon.notice netifd: Interface 'wan6_4_' is now up
Sun Feb 21 21:17:24 2021 daemon.notice netifd: Interface 'wan6_4_' has link connectivity
Sun Feb 21 21:17:24 2021 kern.warn kernel: [ 153.624955] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:24 2021 kern.warn kernel: [ 153.625656] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:24 2021 kern.warn kernel: [ 153.626306] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:24 2021 user.notice firewall: Reloading firewall due to ifup of wan6_4 (map-wan6_4)
Sun Feb 21 21:17:24 2021 kern.warn kernel: [ 154.113044] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:24 2021 kern.warn kernel: [ 154.178135] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:24 2021 kern.warn kernel: [ 154.179029] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:24 2021 kern.warn kernel: [ 154.179394] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:24 2021 kern.warn kernel: [ 154.180414] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:24 2021 kern.warn kernel: [ 154.181077] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:25 2021 kern.warn kernel: [ 154.237926] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:25 2021 kern.warn kernel: [ 154.238745] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:25 2021 kern.warn kernel: [ 154.239487] ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
Sun Feb 21 21:17:25 2021 daemon.debug dnsmasq[1833]: listening on eth0.836(#6): 2a01:e0a:69:xxxx:xxxx:xxxx:xxxx:3 port 53
Sun Feb 21 21:17:26 2021 daemon.debug dnsmasq[1833]: listening on br-lan(#5): 2a01:e0a:69:xxxx::1 port 53
Sun Feb 21 21:17:26 2021 daemon.debug dnsmasq[1833]: listening on eth0.836(#6): 2a01:e01:8:xxxx:xxxx::xxxx port 53
I noticed in thread discussing about WiP port of OpenWrt on NanoPIR4S @BotoX who said: "use r8168-8.048.03 realtek kernel module (much better than r8169)", something I didn't do yet. I'm still using default r8169 kernel module.
=> Could this issue be related to a bug and/or a bad behavior of Realtek driver ?
I'm encountering the same issue with my R7800 running on my own custom 21.02 build.
After router reboot, the router appears to be able to obtained IPv6 network from my ISPs. My ISP is using DHCPv6. It has been working for the longest time that I can remember. But recently I started noticing the lost of IPv6 network.
The router seems to have lost it's IPv6 default route, so IPv6 is effectively down.
Restarting the wan6 interface via Luci seems to restore IPv6, but router only manage to obtain the PD prefix from ISP. Router failed to get IPv6 IP from ISP. Usually router will get a /128 address from ISP.
When I did a tcpdump on the wan interface, IPv6 connectivity is restored. That's when I searched and found that promisc mode enabled all multicast traffic to be sent to the CPU. Searching the Internet also suggest that setting the ALLMULTICAST mode for the wan interface works, and indeed, it works.
Is this a kernel issue or an ISP issue? My OpenWrt configuration has not changed. The only change was to the router firmware, where I periodically pull from the latest 21.02 tree. My router is currently running the 5.4.194 kernel.
This is the result of a combination of factors, all of which involve certain levels of doing the "wrong" thing...
First, OpenWRT's assumption that DHCPv6 from the upstream provider should come from LLA is not valid.
Second, NOBODY should be sending packets with LLA and GUA present in SRC,DST fields. LLA<->LLA or GUA<->GUA, but not LLA<->GUA. In fact, according to the RFCs, any node receiving a packet with both types of address in the header should drop that packet.
Third, OpenWRT's use of fc00::/6 as a catchall for ULA and LLA muddy's the waters and isn't a great choice, either. That prefix encompasses the following addressing classes:
I can only surmise that fc00::/6 was chosen as a lazy way to represent all of ULA+LLA and multicast and the reserved ranges are expected/assumed not to matter in this context (a poor assumption in what is theoretically a secuirty rule).
Unfortunately, since it is perfectly legitimate for an ISP to send DHCPv6 responses from any valid GUA, it's nearly impossible to have any form of address verification in this rule unless you are familiar with the behavior of your particular upstream. Thus, the only rational default for OpenWRT to apply here would be to replace the src_ip and dest_ip options with comments detailing this fact.
Thank you for the suggestion about changing the firewall.
Comcast / Xfinity's recent network upgrade in my neighborhood caused me to run into this very issue!
I'm not sure what was actually necessary, but I changed the Firewall - Traffic Rule:
Allow-DHCPv6 + Allow Source Address ::/0 + Allow Destination Address ::/0
Alternately the source and destination IPs could have been deleted to make it a port rule only, but I wanted them left as comments to remind me what I changed.