IPv6 works only with wan in promiscuous mode

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

  1. start tcpdump -i $wan_interface -vv -w /tmp/dump.pcap
  2. run "ifup wan"
  3. wait 20s
  4. set promiscuous mode
  5. wait 20s
  6. stop tcpdump and email me your pcap file.
1 Like

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 :

  1. 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

  2. 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'

  3. 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

  4. 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.

  1. 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.

  1. 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

  1. 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.

  2. 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

  1. 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.

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?

I have reported the bug:
https://bugs.lede-project.org/index.php?do=details&task_id=580

@gcobb - does setting the interface to promisc mode helps in your case as well?

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:

  • an intermediate ONU/ONT provided by the ISP (transforming 10G-EPON into 1G)
  • a [TP-Link MC220L] for SFP 1G => ethernet 1G conversion
  • an IPv6 stack available on VLAN 836
  • a NanoPI R4S + 'work in progress' support for NanoPi R4S in OpenWrt
  • the package 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 ?