@junky My build targets HW.1.0 and HW.1.1 only, using the mainline rtl8261n driver. Fanboy's ubi2 build uses rtl8261ce which targets HW.2.1, so my build is not recommended if you have W1700K2 variant. Also, the default running LED is actually green fanboy changes it to white in his builds.
2 Likes
Thanks for the info! I recalled that the patch for the rtl8261ce hadn't been merged into the mainline yet, so I figured it was probably targeting HW1.x, and now that confirms it.
I didn't know that. Good to know!
1 Like
I am seeing the same issue with any of the newer ubi2 builds I have tried so far on my HW 1.0. Did you ever figure out a cause? 6ghz never gets beyond ~700Mbps and I have definitely gotten 1.4 Gbps+ in the past
Not yet.. still at 500-600 range. i have 1gbps line. UBI 1 i was getting 1GBPS+ sometime.
1 Like
FYI I did some more reading, and after installing the bridger package i am seeing over 1Gbps again (HW and VLAN offload enabled)
Anyone else seeing RX errors creeping up on the WAN interface? This is over the span of 6 days. Symmetrical fiber 1Gbps (behind a CGNAT, no IPv6, but renting a public IPv4). Already swapped all cables with high quality ones. I haven't seen these on Linksys E8450 that was facing WAN previously.
I am mostly rolling Fanboy's builds, but it's been like this on any build I tried (non-OC too of course). It does not affect actual speeds on the connected devices. And no amount of speed / bloatware tests can actually trigger this. It just happens over time, even at (mostly) idle.
What could be causing this?
Details
[...]:~# ifconfig wan
wan Link encap:Ethernet HWaddr [...]
inet addr:[...] Bcast:[...] Mask:[...]
inet6 addr: [...] Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:60051276 errors:651 dropped:651 overruns:0 frame:0
TX packets:29885588 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:53029173940 (49.3 GiB) TX bytes:6031585800 (5.6 GiB)
Interrupt:46
I don't see any errors on "ifconfig wan" but I do see a complaint on the Status->Flowsense page.
⚠
Physical Bottleneck
Hardware errors detected on WAN (28 rx_errors). Check WAN cable or SFP. Latency stats may be misleading.
I assume these errors are at a lower level (ethernet frame?) and the packets are discarded before the ifconfig errors are collected (probably at the IP level).
(This is on fanboy "OpenWrt ubi2 r35201-b9b60023e6" from 2 days ago.)
Thanks, that is very useful.
I upgraded and retested on a newer UBI2 build, but I still have exactly the same issue.
Current build: ubi2_2026.07.03_r35221-840ee5c7050 from https://github.com/w1700k/builds/releases
Offload is enabled:
flow_offloading=1
flow_offloading_hw=1
When using the normal fw4 flowtable rule, forwarded IPv6 TCP/UDP still breaks for me:
meta l4proto { tcp, udp } flow add @ft
The workaround is still to restrict the flowtable to IPv4 only:
meta nfproto ipv4 meta l4proto { tcp, udp } flow add @ft
With that workaround, IPv4 remains hardware-offloaded and IPv6 is stable again on the software path.
Quick recap:
- without the workaround: IPv4 is fast with hardware offload, but IPv6 is unusable or extremely unstable
- with the IPv4-only flowtable workaround: IPv4 still reaches about 2.3 Gbit/s (on 2.5G ethernet port), while IPv6 becomes stable around 1 Gbit/s
@adrienyhuel Could you please confirm:
-
which W1700K hardware revision you have? Is it HW2.1?
-
So is your WAN interface untagged, or do you use a VLAN on WAN?
-
what is your generated fw4 flowtable rule?
nft -a list chain inet fw4 forward | grep 'flow .*@ft'
My current hypothesis is that this may be specific to one of these cases:
- HW2.1 / RTL8261CE
- routed IPv6 over WAN VLAN
wan.100 - or the interaction between
nft_flow_offload, routed IPv6, WAN VLAN tagging and the RTL8261CE PHY path
As far as I understand, other W1700K hardware revisions do not use exactly the same WAN PHY as HW2.1. So if your unit is not HW2.1, it may explain why you do not reproduce the same issue.
I also saw a comment elsewhere suggesting that UBI2 builds use nft_flow_offload, while other acceleration paths such as bridger may behave differently. However, on HW2.1 the RTL8261CE PHY support is still a constraint, so I cannot easily compare with regular snapshots yet.
Also, if this is not the right place to report this kind of issue, where should I report it?
I can help investigate and test patches/builds if needed. The issue is easy to reproduce on my setup.
Hello,
- My w1700K is HW1
- My WAN in untagged
- flowtable :
meta l4proto { tcp, udp } flow add @ft # handle 325
I suggest you to open a discussion there : https://github.com/orgs/w1700k/discussions
You could get some help from @OpenWRT-fanboy himself, who make those builds.
I have use a VLAN though : wan.100 bridged with lan.100 -> this is mandatory for my tv box which talk to the ISP router throug VLAN 100.
1 Like
I've got hardware 2.1 also and a similar nft rule:
root@gw2:~# nft -a list chain inet fw4 forward | grep 'flow .*@ft' meta l4proto { tcp, udp } flow add @ft # handle 4502
root@gw2:~# uci show | grep offloadfirewall.@defaults[0].flow_offloading='1'firewall.@defaults[0].flow_offloading_hw='1'
I'm seeing 2.3 Gbit/sec download and 350 Mbit/sec upload from multiple internet speed test sites. (That upload is the limit of what my ISP gives me, so I can't easily stress test that.)
I'm on fanboy's OpenWrt ubi2 r35201-b9b60023e6 from 2 days ago.
1 Like
Hello, Here are my test results:
- My hardware is HW 2.1.
meta l4proto { tcp, udp } flow add @ft # handle 268- WAN is tagged with VLAN 2002.
- The firmware version is
ubi2_2026.07.03_r35221-840ee5c705.
I used https://ookla.dualstack.speedtestcustom.com/ for the speed test to confirm I was connecting via IPv6, and I didn't see the CPU cores hitting 100% at all.
cat /etc/config/network
(snip)
config interface 'wan6'
option device 'wan.2002'
option proto 'dhcpv6'
option norelease '1'
config device
option type '8021q'
option ifname 'wan'
option vid '2002'
option name 'wan.2002'
cat /etc/config/dhcp
(snip)
config dhcp 'lan'
option interface 'lan'
option dhcpv4 'server'
option ra 'server'
option dhcpv6 'server'
list dns '2606:4700:4700::1111'
list ra_flags 'managed-config'
list ra_flags 'other-config'
config dhcp 'wan6'
option interface 'wan6'
option ignore '1'
option master '1'
option ra 'relay'
option dhcpv6 'relay'
option ndp 'relay'
I also tested NDProxy, and it worked flawlessly as well.
Hope this helps.
1 Like
Thanks ! There is now another data point on the GitHub discussion:
tompointexe can reproduce the issue too and says it seems to happen with a /60 or larger IPv6 delegated prefix. His real WAN setup is also VLAN 100 on WAN + DHCP, which is very close to mine.
So I think the current hypothesis should be narrowed down to:
- HW2.1
- routed DHCPv6-PD
- /60 or larger delegated IPv6 prefix
- forwarded IPv6 TCP/UDP entering nft_flow_offload/PPE
This may explain why some other tests do not reproduce it:
- HW1 + untagged WAN is a different path
- relay/NDProxy IPv6 is different from routed DHCPv6-PD
@wolfgangrupprecht could you please confirm your IPv6 setup?
- Are your LAN clients using a routed delegated prefix?
- What prefix size do you receive ? /64, /60 or something else?
- Was the 2.3 Gbit/s test definitely over IPv6?
FIY I also tested DHCPv6-PD, but no problem. (2Gbps Up/Down speeds)
/ect/config/dhcp
config dhcp 'wan6'
option interface 'wan6'
option ignore '1'
option master '1'
config dhcp 'lan'
option interface 'lan'
option dhcpv4 'server'
option ra 'server'
option dhcpv6 'server'
1 Like
I receive a /60 from Comcast but only make use of the lowest /64 currently. Yes, the IPv6 is routed in the standard way, no NAT or other translations. Yes, the internet tests were definitely over IPv6 (local address in the /60 delegation 2601:646:8600:183a:: ). I made sure to check that is was really over IPv6 on each test. I'm not sure what is causing the difference we see.
1 Like
@junky Thanks, your datapoint is very interesting because it may narrow the bug scope.
There is an ongoing GitHub discussion/debug thread here:
Gilly1970 identified a confirmed blackhole case on my Bouygues setup with wan.100: the IPv6 flow is programmed into the PPE/HW offload engine with the VLAN 100 tag, but the hardware forwards zero packets on it.
He is working on a test patch/workaround for that case, but your VLAN 2002 result may mean the condition is narrower than just “IPv6 + tagged WAN”.
Could you run Gilly1970’s diag script while doing a forced IPv6 download, to confirm whether your IPv6 flow is actually entering HW_OFFLOAD/PPE?
Script:
Reference command from the GitHub thread:
Example test from a LAN client:
curl -6 -L -o /dev/null http://scaleway.testdebit.info/1G.iso
And on the router while the download is running:
sh /tmp/ppe-v6-diag.sh 15 > /tmp/ppe-v6-diag.log 2>&1; cat /tmp/ppe-v6-diag.log
If your VLAN 2002 IPv6 flow shows [HW_OFFLOAD] and non-zero PPE packet counters, that would be a very useful comparison against my wan.100 blackhole case.
1 Like
Here are my test results:
-- IPv6 conntrack + offload flag ([OFFLOAD]/[HW_OFFLOAD] = handed to PPE):
Since there are so many entries, I believe hardware offloading is most likely working.
root@OpenWrt:~# sh ppe-v6diag.sh 15
==================================================================
Airoha PPE IPv6 offload diagnostics (Mon Jul 6 09:34:59 GMT 2026)
==================================================================
### Offload switches (nftables flowtable + sysctls) #############
flowtable ft {
meta l4proto { tcp, udp } flow add @ft
meta nfproto ipv4 udp dport 68 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCP-Renew"
meta nfproto ipv4 meta l4proto igmp counter packets 0 bytes 0 accept comment "!fw4: Allow-IGMP"
meta nfproto ipv6 udp dport 546 counter packets 25 bytes 6050 accept comment "!fw4: Allow-DHCPv6"
meta nfproto ipv4 oifname { "wan.11", "wan.2002" } ct state invalid counter packets 456 bytes 26384 drop comment "!fw4: Prevent NAT leakage"
meta nfproto ipv4 masquerade comment "!fw4: Masquerade IPv4 wan traffic"
net.netfilter.nf_flowtable_* :
net.netfilter.nf_flowtable_tcp_timeout = 30
net.netfilter.nf_flowtable_udp_timeout = 30
### IPv6 WAN reachability (routing sanity - check this FIRST) ###
-- default route(s) (OpenWrt PD installs 'default from <prefix>' source-specific routes):
default from *:*:*:1c00::/64 via fe80::569b:49ff:fe44:2ad8 dev wan.2002 metric 512
default from *:*:*:1c10::/60 via fe80::569b:49ff:fe44:2ad8 dev wan.2002 metric 512
-- can the router route to the v6 internet? (route get 2606:4700:4700::1111 from *:*:*:1c10::1):
2606:4700:4700::1111 from *:*:*:1c10::1 via fe80::569b:49ff:fe44:2ad8 dev wan.2002 src *:*:*:1c00:8670:3ff:fe53:bd98 metric 512
-- WAN device / v6 gateway: wan.2002 / fe80::569b:49ff:fe44:2ad8
-- WAN global address(es) (need >=1, else no PD / RA):
*:*:*:1c00:8670:3ff:fe53:bd98/64
-- v6 gateway neighbour state (want REACHABLE/STALE/DELAY, NOT FAILED/INCOMPLETE):
fe80::569b:49ff:fe44:2ad8 dev wan.2002 lladdr 54:9b:49:44:2a:d8 router ref 1 used 0/0/0 probes 1 REACHABLE
### Forwarding / firewall / MTU sanity (his-setup vs bug) ######
net.ipv6.conf.all.forwarding = 1 (must be 1)
MTU wan.2002 = 1500
MTU br-lan = 1500
-- fw4 v6 forward/drop counters (a climbing drop here = firewall, not PPE):
type filter hook forward priority filter; policy drop;
jump handle_reject
-- IPv6 conntrack + offload flag ([OFFLOAD]/[HW_OFFLOAD] = handed to PPE):
ipv6 10 udp 17 99 src=*:*:*:1c10:020c:29ff:fec5:6326 dst=2401:d560:0000:0105:1c00:daff:fe00:0219 sport=43299 dport=123 packets=1 bytes=96 src=2401:d560:0000:0105:1c00:daff:fe00:0219 dst=*:*:*:1c10:020c:29ff:fec5:6326 sport=123 dport=43299 packets=1 bytes=96 mark=0 zone=0 use=2
ipv6 10 udp 17 49 src=*:*:*:1c10:3975:7705:a9b9:468e dst=*:*:*:1c10:0000:0000:0000:0001 sport=63252 dport=53 packets=1 bytes=77 src=*:*:*:1c10:0000:0000:0000:0001 dst=*:*:*:1c10:3975:7705:a9b9:468e sport=53 dport=63252 packets=1 bytes=157 mark=0 zone=0 use=2
ipv6 10 udp 17 16 src=*:*:*:1c00:8670:03ff:fe53:bd98 dst=*:*:*:1c00:569b:49ff:fe44:2ad8 sport=37938 dport=53 packets=1 bytes=105 src=*:*:*:1c00:569b:49ff:fe44:2ad8 dst=*:*:*:1c00:8670:03ff:fe53:bd98 sport=53 dport=37938 packets=1 bytes=158 mark=0 zone=0 use=2
ipv6 10 tcp 6 7221 ESTABLISHED src=*:*:*:1c10:29e2:f688:538d:c2cd dst=2001:4860:4802:0038:0000:0000:0000:0223 sport=37694 dport=443 packets=9 bytes=2723 src=2001:4860:4802:0038:0000:0000:0000:0223 dst=*:*:*:1c10:29e2:f688:538d:c2cd sport=443 dport=37694 packets=10 bytes=2231 [ASSURED] mark=0 zone=0 use=2
ipv6 10 tcp 6 6366 ESTABLISHED src=*:*:*:1c10:3975:7705:a9b9:468e dst=2404:6800:400b:c01b:0000:0000:0000:00bc sport=44759 dport=5228 packets=89 bytes=9755 src=2404:6800:400b:c01b:0000:0000:0000:00bc dst=*:*:*:1c10:3975:7705:a9b9:468e sport=5228 dport=44759 packets=168 bytes=14884 [ASSURED] mark=0 zone=0 use=2
ipv6 10 tcp 6 src=*:*:*:1c10:020c:29ff:fec5:6326 dst=2001:0bc8:0003:0000:0000:0000:0000:0007 sport=60522 dport=80 packets=40 bytes=2981 src=2001:0bc8:0003:0000:0000:0000:0000:0007 dst=*:*:*:1c10:020c:29ff:fec5:6326 sport=80 dport=60522 packets=48 bytes=69152 [HW_OFFLOAD] mark=0 zone=0 use=3
ipv6 10 tcp 6 1 CLOSE src=*:*:*:1c10:020c:29ff:fec5:6326 dst=2a04:4e42:0000:0000:0000:0000:0000:0644 sport=48906 dport=80 packets=33 bytes=2806 src=2a04:4e42:0000:0000:0000:0000:0000:0644 dst=*:*:*:1c10:020c:29ff:fec5:6326 sport=80 dport=48906 packets=15 bytes=42390 [ASSURED] mark=0 zone=0 use=2
ipv6 10 udp 17 49 src=*:*:*:1c00:8670:03ff:fe53:bd98 dst=*:*:*:1c00:569b:49ff:fe44:2ad8 sport=34124 dport=53 packets=1 bytes=88 src=*:*:*:1c00:569b:49ff:fe44:2ad8 dst=*:*:*:1c00:8670:03ff:fe53:bd98 sport=53 dport=34124 packets=1 bytes=147 mark=0 zone=0 use=2
ipv6 10 tcp 6 1 CLOSE src=*:*:*:1c10:020c:29ff:fec5:6326 dst=2a04:4e42:0600:0000:0000:0000:0000:0644 sport=59768 dport=80 packets=33 bytes=2870 src=2a04:4e42:0600:0000:0000:0000:0000:0644 dst=*:*:*:1c10:020c:29ff:fec5:6326 sport=80 dport=59768 packets=13 bytes=42952 [ASSURED] mark=0 zone=0 use=2
ipv6 10 tcp 6 7205 ESTABLISHED src=*:*:*:1c10:29e2:f688:538d:c2cd dst=2404:6800:400a:1000:0000:0000:0000:005f sport=42838 dport=443 packets=8 bytes=1959 src=2404:6800:400a:1000:0000:0000:0000:005f dst=*:*:*:1c10:29e2:f688:538d:c2cd sport=443 dport=42838 packets=9 bytes=3260 [ASSURED] mark=0 zone=0 use=2
ipv6 10 tcp 6 6 CLOSE src=*:*:*:1c10:020c:29ff:fec5:6326 dst=2a04:4e42:0400:0000:0000:0000:0000:0644 sport=54510 dport=80 packets=34 bytes=2603 src=2a04:4e42:0400:0000:0000:0000:0000:0644 dst=*:*:*:1c10:020c:29ff:fec5:6326 sport=80 dport=54510 packets=12 bytes=43045 [ASSURED] mark=0 zone=0 use=2
ipv6 10 tcp 6 7145 ESTABLISHED src=*:*:*:1c10:29e2:f688:538d:c2cd dst=2404:6800:400b:c017:0000:0000:0000:00bc sport=40868 dport=5228 packets=212 bytes=19121 src=2404:6800:400b:c017:0000:0000:0000:00bc dst=*:*:*:1c10:29e2:f688:538d:c2cd sport=5228 dport=40868 packets=212 bytes=93384 [ASSURED] mark=0 zone=0 use=2
ipv6 10 udp 17 93 src=*:*:*:1c10:020c:29ff:fec5:6326 dst=2401:d560:0000:0105:1c00:daff:fe00:0219 sport=49829 dport=123 packets=1 bytes=96 src=2401:d560:0000:0105:1c00:daff:fe00:0219 dst=*:*:*:1c10:020c:29ff:fec5:6326 sport=123 dport=49829 packets=1 bytes=96 mark=0 zone=0 use=2
ipv6 10 tcp 6 6816 ESTABLISHED src=*:*:*:1c10:1519:5c64:040e:a375 dst=2404:6800:400b:c015:0000:0000:0000:00bc sport=42044 dport=5228 packets=74 bytes=7547 src=2404:6800:400b:c015:0000:0000:0000:00bc dst=*:*:*:1c10:1519:5c64:040e:a375 sport=5228 dport=42044 packets=91 bytes=13849 [ASSURED] mark=0 zone=0 use=2
ipv6 10 udp 17 49 src=*:*:*:1c10:3975:7705:a9b9:468e dst=*:*:*:1c10:0000:0000:0000:0001 sport=48606 dport=53 packets=1 bytes=77 src=*:*:*:1c10:0000:0000:0000:0001 dst=*:*:*:1c10:3975:7705:a9b9:468e sport=53 dport=48606 packets=1 bytes=136 mark=0 zone=0 use=2
(nf_conntrack not readable)
### WAN6 / RA / DHCPv6-PD log tail (upstream-provisioning health) ##
-- recent odhcp6c / RA / DHCPv6 / prefix events (last 20):
Sun Jul 5 13:50:15 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Sun Jul 5 14:50:15 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Sun Jul 5 15:50:15 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Sun Jul 5 16:50:16 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Sun Jul 5 17:50:16 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Sun Jul 5 18:50:15 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Sun Jul 5 19:50:15 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Sun Jul 5 20:50:15 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Sun Jul 5 21:50:15 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Sun Jul 5 22:50:15 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Sun Jul 5 23:50:16 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Mon Jul 6 00:50:16 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Mon Jul 6 01:50:16 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Mon Jul 6 02:50:16 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Mon Jul 6 03:50:16 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Mon Jul 6 04:50:16 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Mon Jul 6 05:50:16 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Mon Jul 6 06:50:17 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Mon Jul 6 07:50:17 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
Mon Jul 6 08:50:17 2026 daemon.notice netifd: wan (9802): udhcpc: sending renew to server 172.20.11.1
-- v6-related errors/warnings in log (last 15):
Sat Jul 4 02:21:41 2026 daemon.notice netifd: wan6 (3479): wan.2002: error connecting LLA socket
Sat Jul 4 02:21:41 2026 daemon.notice netifd: wan6 (3479): wan.2002: error connecting LLA socket
Sat Jul 4 02:21:41 2026 daemon.notice netifd: wan6 (3479): wan.2002: error connecting LLA socket
Sat Jul 4 02:21:41 2026 daemon.notice netifd: wan6 (3479): wan.2002: error connecting LLA socket
Sat Jul 4 02:21:41 2026 daemon.notice netifd: wan6 (3479): wan.2002: error connecting LLA socket
Sat Jul 4 02:21:41 2026 daemon.notice netifd: wan6 (3479): wan.2002: error connecting LLA socket
Sat Jul 4 02:21:41 2026 daemon.notice netifd: wan6 (3479): wan.2002: error connecting LLA socket
Sat Jul 4 02:21:41 2026 daemon.notice netifd: wan6 (3479): wan.2002: error connecting LLA socket
Sat Jul 4 02:21:41 2026 daemon.notice netifd: wan6 (3479): wan.2002: error connecting LLA socket
Sat Jul 4 02:21:41 2026 daemon.notice netifd: wan6 (3479): wan.2002: error connecting LLA socket
Sat Jul 4 02:21:42 2026 daemon.notice netifd: radio1 (3580): command failed: Not supported (-95)
Sat Jul 4 02:21:42 2026 daemon.notice netifd: radio2 (3703): command failed: Not supported (-95)
Sat Jul 4 02:24:20 2026 daemon.notice netifd: wan (3427): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan" } (Permission denied)
Sat Jul 4 02:25:48 2026 kern.warn kernel: [ 211.449542] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_inet pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack nct7802 mt7996e(O) mt76_connac_lib(O) mt76(O) mac80211(O) cfg80211(O) slhc regmap_i2c nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 compat(O) i2c_mt7621 i2c_dev ip6_tunnel tunnel6 sha512 libsha512 seqiv sha3_generic jitterentropy_rng drbg crypto_hw_eip93 sha256 sha1 md5 libmd5 hmac geniv des_generic libdes cmac authencesn authenc leds_gpio mt7530_mmio mt7530_dsa airoha_eth airoha_npu gpio_button_hotplug(O) rtk_rtl8261ce_phy realtek hwmon i2c_core
Sat Jul 4 07:50:12 2026 daemon.notice netifd: wan4 (17140): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan4" } (Permission denied)
### Delegated-prefix routing (the /60 tell-tale) ################
-- unreachable aggregate route(s) (present for /60+, absent for a bare /64):
unreachable *:*:*:1c00::/64 dev lo metric 2147483647
unreachable *:*:*:1c10::/60 dev lo metric 2147483647
-- on-link LAN prefixes:
*:*:*:1c00::/64 dev wan.2002 metric 256
*:*:*:1c10::/64 dev br-lan metric 1024
### Hardware-bound IPv6 flows (window = 15s) #############
legend: PKT_DELTA = packets the PPE forwarded in the window.
A climbing delta while the client sees nothing = HW black-hole.
ID DST_IP NEXTHOP_MAC PKT_DLT NEIGHBOUR / VERDICT
------ ---------------------------------------- ----------------- --------- -------------------
005bc 2001:0bc8:0003:0000:0000:0000:0000:0007 54:9b:49:44:2a:d8 0 fe80::569b:49ff:fe44:2ad8 dev wan.2002 REACHABLE
026e0 *:*:*:1c10:020c:29ff:fec5:6326 00:0c:29:c5:63:26 0 fe80::20c:29ff:fec5:6326 dev br-lan DELAY
### Raw FOE entry bytes (what the HW actually got programmed) ##
For the VLAN black-hole hunt: on the IPv6 upload entry (egress wan.<vid>),
check eth=SMAC->DMAC (v6 uses an SMAC-ID table, not an inline MAC),
etype (want 86dd), and vlan=<vid>,<vid2>. Compare against a working IPv4
line: if the v6 SMAC or vlan= differs from the v4 one, that's the smoking gun.
ib1 decode: VLAN_LAYER=bits19:16 VPM=bits21:20 (both = #vlan tags to push)
-- IPv6 bind entries (raw):
005bc BND IPv6 5T orig=*:*:*:1c10:020c:29ff:fec5:6326:60522->2001:0bc8:0003:0000:0000:0000:0000:0007:80 eth=00:02:00:00:00:00->54:9b:49:44:2a:d8 etype=86dd data=007f1000 vlan=2002,0 ib1=2b110874 ib2=0003e240 packets=0 bytes=0
026e0 BND IPv6 5T orig=2001:0bc8:0003:0000:0000:0000:0000:0007:80->*:*:*:1c10:020c:29ff:fec5:6326:60522 eth=00:01:00:00:00:00->00:0c:29:c5:63:26 etype=8004 data=007f1000 vlan=0,0 ib1=2b000874 ib2=0003e622 packets=0 bytes=0
-- IPv4 bind entries (raw, working reference - up to 4):
(none bound)
ib1[005bc]=2b110874 -> VLAN_LAYER=1 VPM=1 (both should = #tags pushed on egress)
ib1[026e0]=2b000874 -> VLAN_LAYER=0 VPM=0 (both should = #tags pushed on egress)
### Traffic flow over the window (where does it stop?) ########
RX = packets the iface received, TX = packets it sent, DROP = dropped.
Download stalling: WAN RX climbs but LAN TX flat = forwarding black-hole.
IFACE RX_pkts TX_pkts RX_drop TX_drop
eth0 21682 152989 0 0
wan.2002 7 3 0 0
phy0.1-ap0 1 0 0 0
wan.11 8 8 0 0
br-lan 59 72 0 0
wan 152944 21636 0 0
lan4 21683 152992 0 0
(all-zero table = no traffic in window; re-run during an active v6 download)
### Kernel route decision for each bound IPv6 dst ###############
(download flows: dst = a LAN client; watch for 'unreachable' or wrong dev)
2001:0bc8:0003:0000:0000:0000:0000:0007 -> 2001:bc8:3::7 from *:*:*:1c10::1 via fe80::569b:49ff:fe44:2ad8 dev wan.2002 src *:*:*:1c00:8670:3ff:fe53:bd98 metric 512
*:*:*:1c10:020c:29ff:fec5:6326 -> *:*:*:1c10:20c:29ff:fec5:6326 from *:*:*:1c10::1 dev br-lan src *:*:*:1c10::1 metric 1024
==================================================================
Decision tree: IS IT HIS SETUP, OR AN ACTUAL PPE HW BUG?
==================================================================
Run this DURING an active IPv6 download from a stalling LAN client,
then read top-down - the first matching branch wins:
[SETUP] No default route, or route-get says 'unreachable' even WITH a
source -> WAN6 RA/DHCPv6-PD is broken. Not a PPE bug. Fix WAN6.
[SETUP] v6 gateway neighbour FAILED/INCOMPLETE, or WAN has no global
address -> upstream link/RA problem. Not a PPE bug.
[SETUP] net.ipv6.conf.all.forwarding = 0, or fw4 forward 'drop' counter
climbs -> forwarding/firewall config. Not a PPE bug.
[SETUP] WAN MTU < 1500 or PMTU stalls only large transfers -> MTU/PMTUD.
[INCONCLUSIVE] Traffic table all-zero -> nothing was flowing; the client
wasn't actually downloading. Re-run under real load.
[HW BUG] WAN RX_pkts CLIMBS but LAN TX_pkts stays FLAT (or vice-versa)
AND the flow shows [OFFLOAD] in conntrack AND PPE PKT_DLT is 0
-> packets enter, get handed to HW, and vanish = PPE black-hole.
[HW BUG] PKT_DLT CLIMBS to a NULL/unknown/stale NEXTHOP_MAC while the
client stalls -> HW forwarding to a dead next-hop = black-hole.
[HW BUG] NEXTHOP_MAC is REACHABLE + PKT_DLT climbs + client still stalls
-> PPE IPv6-route (non-NAT) mishandling. The 'meta nfproto ipv4'
workaround (v4-only offload) should make the stall disappear;
that A/B is the definitive confirmation.
==================================================================
I hope this information is helpful.
2 Likes
@junky Thanks, this is useful.
Gilly looked at your capture on GitHub, and your VLAN 2002 case may actually show the same fingerprint as my VLAN 100 case:
- conntrack shows
[HW_OFFLOAD] - FOE entry is programmed with
vlan=2002,0 VLAN_LAYER=1/VPM=1- but the PPE counters stay at
packets=0 bytes=0
So it may not be a clean “tagged WAN works” counterexample after all. It may be the same small-burst-then-stall pattern, but we need one cleaner under-load capture to confirm.
Could you rerun one test and post the result directly in the GitHub discussion so Gilly can read it in one place?
GitHub thread:
First, on the router, grab the latest diag script:
wget -O /tmp/ppe-v6-diag.sh https://raw.githubusercontent.com/Gilly1970/Gemtek-W1700K-6.18/main/openwrt-patches/ppe-v6-diag.sh
chmod +x /tmp/ppe-v6-diag.sh
Please run the test with the normal full flowtable rule active:
meta l4proto { tcp, udp } flow add @ft
and with hardware flow offload enabled:
flow_offloading=1
flow_offloading_hw=1
Then open two terminals.
On a LAN client ( ideally who can reach 2Gbps or more) then start a sustained forced-IPv6 download:
curl -6 -L --connect-timeout 5 --max-time 60 \
-o /dev/null \
-w "exit=%{exitcode} http=%{http_code} total=%{time_total} bytes=%{size_download} speed=%{speed_download} remote=%{remote_ip}\n" \
http://scaleway.testdebit.info/10G.iso
While that download is actively running or stalling, run this on the router:
sh /tmp/ppe-v6-diag.sh 15 > /tmp/ppe-v6-diag.log 2>&1; cat /tmp/ppe-v6-diag.log
Please post both outputs on GitHub:
- the client-side curl result
- the router-side /tmp/ppe-v6-diag.log
Thanks!
Is it normal that having "Error: failed - bridge module may not be loaded" errors when I try to enable "VLAN and PPPoE" offload options from disable to enable with latest community build? (ubi2_2026.07.09_r35312-819035eac6)
I also installed "bridger" package from software section but doesn't helps. Indeed I don't have any VLAN or PPPoE interface defined in configurations right now but ... with previous versions, I am able to enable those 2 options.
kmod-pppoe is installed? The bridger package is only optional on dumb ap, not on main routers.
yes. Installed and loaded. I was able to set them "enable" on previous fw. Not actually use pppoe and vlan it but just want to feedback about it... Might be something is broken. I installed "bridger" package just because of the error appears when I try to enable offload for vlan and pppoe