Release Asuswrt-Merlin 386.7 is now available for all models

[Treadler]

No problems, and that’s how it usually is set, and therefore no packet rewrites (if my theory is correct).

Did you force your test client to only use an external IPv6 DNS server?

No, so forcing the iPad to Quad9 IPv6 direct upset the logs…..
Below is just a small sample.

Jun 27 21:21:22 kernel: <unknown>: hw csum failure
Jun 27 21:21:22 kernel: CPU: 1 PID: 30568 Comm: dnsmasq Tainted: P O 4.1.51 #2
Jun 27 21:21:22 kernel: Hardware name: Broadcom-v8A (DT)
Jun 27 21:21:22 kernel: Call trace:
Jun 27 21:21:22 kernel: [<ffffffc000087658>] dump_backtrace+0x0/0x150
Jun 27 21:21:22 kernel: [<ffffffc0000877bc>] show_stack+0x14/0x20
Jun 27 21:21:22 kernel: [<ffffffc00052afc8>] dump_stack+0x90/0xb0
Jun 27 21:21:22 kernel: [<ffffffc0003dd194>] netdev_rx_csum_fault+0x3c/0x50
Jun 27 21:21:22 kernel: [<ffffffc0003d2408>] skb_copy_and_csum_datagram_msg+0xe8/0xf8
Jun 27 21:21:22 kernel: [<ffffffc0004d5bf8>] udpv6_recvmsg+0x2a0/0x7d8
Jun 27 21:21:22 kernel: [<ffffffc000484654>] inet_recvmsg+0xa4/0xc8
Jun 27 21:21:22 kernel: [<ffffffc0003bf57c>] sock_recvmsg+0x14/0x20
Jun 27 21:21:22 kernel: [<ffffffc0003c118c>] ___sys_recvmsg+0xac/0x1a8
Jun 27 21:21:22 kernel: [<ffffffc0003c3bc0>] __sys_recvmsg+0x40/0x80
Jun 27 21:21:22 kernel: [<ffffffc0004019d0>] compat_SyS_recvmsg+0x10/0x18
Jun 27 21:21:22 kernel: <unknown>: hw csum failure
Jun 27 21:21:22 kernel: CPU: 1 PID: 30568 Comm: dnsmasq Tainted: P O 4.1.51 #2
Jun 27 21:21:22 kernel: Hardware name: Broadcom-v8A (DT)
Jun 27 21:21:22 kernel: Call trace:
Jun 27 21:21:22 kernel: [<ffffffc000087658>] dump_backtrace+0x0/0x150
Jun 27 21:21:22 kernel: [<ffffffc0000877bc>] show_stack+0x14/0x20
Jun 27 21:21:22 kernel: [<ffffffc00052afc8>] dump_stack+0x90/0xb0
Jun 27 21:21:22 kernel: [<ffffffc0003dd194>] netdev_rx_csum_fault+0x3c/0x50
Jun 27 21:21:22 kernel: [<ffffffc0003d2408>] skb_copy_and_csum_datagram_msg+0xe8/0xf8
Jun 27 21:21:22 kernel: [<ffffffc0004d5bf8>] udpv6_recvmsg+0x2a0/0x7d8

 

[dave14305]

ran the DNS check via the url posted @dave14305 but it was absolutely fine / 100% / 3 Stars etc

The test results aren’t really important. That was just the first site I thought of that would create some unique uncached DNS lookups on demand, across multiple query types.

 

[Pergola Fabio]

is it neccesary to updated the nodes too , with newer stock firmware? when upgrading to this new 386.7 ?
i'm still running this one on stock : 3.0.0.4.386_46092-g0d2214a (rt-ac86u)

 

[plush19]

Dirty flashed my RT-AC86U from 386.5_2 to 386.7 and pretty stable so far, ill have a look at static IP allocations (DHCP) and IPv6 when time allows me.

 

[SheikhSheikha]

Haven't gone through the entire thread to see if this happened to anyone else, but didn't see any in the few pages I've gone through.
Did the usual dirty upgrade from the previous non beta on my 5300 and at the end of the process it said to manually reboot. I have never seen that message before. It always just reboots itself. So I wait a bit then turn off the router and back on, and all I get is the mini server or whatever it is. So I turn it off and unplug it and wait a minute, then all back on. Same thing.
So... damn. Don't have my settings backed up, this sucks. I guess I need to hit the reset to defaults setting. I do that, and reboot, and same thing, the mini server.
So I reload the firmware again, and after that finishes, AGAIN, back to the mini server, do a reset settings etc, still there, the mini server.

Is this bricked? WTF is going on? Never had a problem anything like this before? What should I do?

You could try a WPS reset (turn off the router. press the wps button and keep it pressed. Turn on power and wait till the most left light blinks (may take up to 30+ seconds before that happens). Then release the wps button.

 

[evildoer]

So I had to do a "firmware restoration" procedure, and even that didn't go smoothly because the program kept saying the router was not in firmware restoration mode. After the 3rd try of doing that (yes the power indicator was flashing slowly each time) it finally worked.
Not sure why this happened. I've been upgrading the same way for many years and never had a problem like this.

 

[Tvlz]

What aspect was broken? Or what does the patch really achieve? The PD request was “auto” before the patch (size 0), but it seems it does not help the router at all to request and receive a larger prefix.

The patch added the ability to request subnets from your ISP that you could use, if you don't ask for them you will only get their default prefix size, most times a /64.

Was it wrong to assign a /60 to br0 before the patch? I only received a /64 from my ISP by default before this patch, so never had a problem before.

Yes, with anything larger then a /64 you are no longer talking about addresses but subnets of /64.

Now I request a /60 just for fun, but can’t easily use it.

You can search in the syslog for "WAN Prefix Size" to see the Requested & Received prefix sizes.

Depending on your ISP it may not be easy to switch prefixes, sometimes they get stuck unless you remove the IPv6 DUID, I think?


BTW::
Everybody when you mention "MY ISP" please SPECIFY your ISP name, they are different especially with IPv6.

 

[automaton]

Your jffs partition size is 62.75 and should be 48.

Back up that partition, then wipe the jffs and restore from backup.

Thanks for the reply. I don't think I use the JFFS for anything in particular, do I still need to back it up? If so, how do I do that?

I'm also not sure how it could go beyond 48, I haven't done anything with it. For example, "Enable JFFS custom scripts and configs" is set to "No"

 

[RMerlin]

Any way to debug why IPV6 (native) doesn't "fetch" address with 386.7 (betas and final) from my ISP
original firmware is gerrting IPV6 fine

No idea, IPv6 isn't my area of expertise, and my ISP isn't expected to support it for years. Any issue there would have to be handled upstream by Asus.

No problems, and that’s how it usually is set, and therefore no packet rewrites (if my theory is correct).

That's weird, I would expect it to behave similarly to IPv4 there. Worst case scenario I can always disable IPv6 support from Router mode I guess.

 

[visortgw]

I flashed 386.7 onto my GT-AX6000 mesh which comprises 5 x AX6000 units ; 2 nodes ethernet attached to the Router and 2 nodes ethernet daisy chained off one of the said nodes. Under Merlin 386.6 the setup works fine but under 386.7 when you complete the firmware upgrade of all 5 routers the 3 daisy chained routers drop out and disappear from the mesh (as if you deleted them). This also occurred with the Asus latest firmware 49273 which actually caused me to seek out Merlin 386.6 !

After several attempts recreating the mesh from scratch, it is consistent that under 386.7 the 3 daisy chained nodes drop out; only the nodes directly attached to the router stay active in 386.7. When I revert to 386.6 all 5 routers work perfectly and at full speed. No doubt this is an ASUS issue and the latest Merlin includes the bad gpl. Has anyone found a similar issue ?, I have a 4 storey house hence the 5 nodes, in case you were wondering.

I fear I may be stuck at Merlin 386.6 forever, it was painful recovering !

I have similar, but different issue with configuring GT-AX6000 as AiMesh node connected to GT-AX6000 primary router. I started another thread a couple of days ago: GT-AX6000 as AiMesh Node?.

I have the issue as described in the the other thread whether the node is directly connected to primary router or connected via TP-Link TL-SG3210XHP-M2 1.0 10/2.5 Gbps managed switch. I have other AiMesh nodes ((2) RT-AX86U (2.5 Gbps wired backhaul) and RT-AX82 (5 GHz 160 Mhz wireless backhaul)) that connect and operate as they should.

 

[dave14305]

The test results aren’t really important. That was just the first site I thought of that would create some unique uncached DNS lookups on demand, across multiple query types.

I can simplify my repro step down to running this on a Windows client:

nslookup qname.6465ta9rbl5051tumbrdnl4cb8.cmdns.dev.dns-oarc.net 2606:4700:4700::1112

 

[John Fitzgerald]

Thanks for the reply. I don't think I use the JFFS for anything in particular, do I still need to back it up? If so, how do I do that?

I'm also not sure how it could go beyond 48, I haven't done anything with it. For example, "Enable JFFS custom scripts and configs" is set to "No"

Read a little further down from your previous post:

EDIT: Your info: If it's not used it should be ( 0 / 63 )

NVRAM usage 57201 / 65536 bytes
JFFS 4.17 / 62.75 MB

I was corrected yesterday that some platforms have a 63mb JFFS. Varies by model.
Mine is now 47. Not 48 which was in error during the alpha and beta1 testing.

As far as factory wiping goes, see here:

After upgrade to 386.7 warning about low level of free NVRAM

Hello, After upgading my ASUS RT-AC68U to the new 386.7 version of Merlin there is a flashing warning in top right corner of the GUI saying: "Your router is running low on free NVRAM, which might affect its stability. Review long parameter lists (like DHCP reservations), or consider doing a...

www.snbforums.com

The JFFS wipe is here:

Release - Asuswrt-Merlin 386.7 is now available for all models

AX58U Anyone else notice AiProtection isn't logging malicious site blocks now? It was working in Beta 2, but now I'm not seeing anything logged in AiProtection. I tested that the feature is working, the blocked events show up in the system log, but not on the AiProtection tab. I've had that...

www.snbforums.com

 

[omrij]

No idea, IPv6 isn't my area of expertise, and my ISP isn't expected to support it for years. Any issue there would have to be handled upstream by Asus.



That's weird, I would expect it to behave similarly to IPv4 there. Worst case scenario I can always disable IPv6 support from Router mode I guess.

Thanks
Asus firmware works fine with native IPV6
it's something with 386.7 that causing it
Thanks anyway
I'll try again with next release

 

[Daemoen]

My setup:
ATT Synchronous GB Fiber (with working/validated ~980Mbit both sides)
2x AX88u
1x AX92u

All in AIMesh via Ethernet Backhaul

Dirty upgraded from 386.5_2 to 386.7. Unfortunately still having the frequent WAN drops requiring a reboot. Not running pihole or anything fancy. Going to try a 'full reset' later, but doing that with 5_2 and the past several has made no difference. This is the first time(s) in years I have been sadly disappointed by AWRT. Did an upgrade back in January, and ever since, have been having to do reboots on the almost daily basis because wan goes 'offline'. Status says it's connected, but unable to ping any ip addresses, so it's not just the DNS issue I have seen reported.

Truly hoping that whatever causes this offline that some of us keep getting stuck with gets resolved soon.

 

[sardelkin]

have this reconnect problem with 2,4ghz after upgrade ax86u from 386.5_2 tо 386.7, factory reset did't help
with 5ghz all fine

Spoiler: part of log

Jun 27 20:17:01 kernel: wl0: random key value: B7FE383025BA9FF46CBC0049871F84AC40892E81C5EA0EF9A16B3146860B3AA0
Jun 27 20:17:01 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jun 27 20:17:01 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: disassociated
Jun 27 20:17:03 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:03 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Unspecified reason (1)
Jun 27 20:17:03 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:03 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: associated
Jun 27 20:17:03 wlceventd: wlceventd_proc_event(534): eth6: Assoc CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:03 hostapd: eth6: STA ce:92:d7:3b:bd:47 RADIUS: starting accounting session CAD78D6801D55826
Jun 27 20:17:03 hostapd: eth6: STA ce:92:d7:3b:bd:47 WPA: pairwise key handshake completed (RSN)
Jun 27 20:17:03 dnsmasq-dhcp[3129]: DHCPREQUEST(br0) 192.168.1.50 ce:92:d7:3b:bd:47
Jun 27 20:17:03 dnsmasq-dhcp[3129]: DHCPACK(br0) 192.168.1.50 ce:92:d7:3b:bd:47 realme-9-Pro
Jun 27 20:17:06 kernel: wl0: random key value: 29099BDFB9616C7B2AA300EC31FD88213E6E30BC3EAE06338ED14B4DA87F3261
Jun 27 20:17:06 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: disassociated
Jun 27 20:17:06 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jun 27 20:17:07 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:07 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: associated
Jun 27 20:17:07 wlceventd: wlceventd_proc_event(534): eth6: Assoc CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:07 hostapd: eth6: STA ce:92:d7:3b:bd:47 RADIUS: starting accounting session 420BBD35811AFD4B
Jun 27 20:17:07 hostapd: eth6: STA ce:92:d7:3b:bd:47 WPA: pairwise key handshake completed (RSN)
Jun 27 20:17:08 dnsmasq-dhcp[3129]: DHCPREQUEST(br0) 192.168.1.50 ce:92:d7:3b:bd:47
Jun 27 20:17:08 dnsmasq-dhcp[3129]: DHCPACK(br0) 192.168.1.50 ce:92:d7:3b:bd:47 realme-9-Pro
Jun 27 20:17:10 kernel: wl0: random key value: 5CBE85A7445E9D757E2C02FF18C1B621226D652C80C60D3B38125B9791A061F9
Jun 27 20:17:10 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jun 27 20:17:10 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: disassociated
Jun 27 20:17:11 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:12 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Unspecified reason (1)
Jun 27 20:17:12 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:12 wlceventd: wlceventd_proc_event(534): eth6: Assoc CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:12 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: associated
Jun 27 20:17:12 hostapd: eth6: STA ce:92:d7:3b:bd:47 RADIUS: starting accounting session FB3DCC09BF627780
Jun 27 20:17:12 hostapd: eth6: STA ce:92:d7:3b:bd:47 WPA: pairwise key handshake completed (RSN)
Jun 27 20:17:12 dnsmasq-dhcp[3129]: DHCPREQUEST(br0) 192.168.1.50 ce:92:d7:3b:bd:47
Jun 27 20:17:12 dnsmasq-dhcp[3129]: DHCPACK(br0) 192.168.1.50 ce:92:d7:3b:bd:47 realme-9-Pro
Jun 27 20:17:15 kernel: wl0: random key value: 51BF983FE09B8B670F6901FFC7142D962221108B7756022EB9DCF06D79602C76
Jun 27 20:17:15 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: disassociated
Jun 27 20:17:15 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jun 27 20:17:16 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:16 wlceventd: wlceventd_proc_event(534): eth6: Assoc CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:16 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: associated
Jun 27 20:17:16 hostapd: eth6: STA ce:92:d7:3b:bd:47 RADIUS: starting accounting session 9D04AC91EFBBE279
Jun 27 20:17:16 hostapd: eth6: STA ce:92:d7:3b:bd:47 WPA: pairwise key handshake completed (RSN)
Jun 27 20:17:16 dnsmasq-dhcp[3129]: DHCPREQUEST(br0) 192.168.1.50 ce:92:d7:3b:bd:47
Jun 27 20:17:16 dnsmasq-dhcp[3129]: DHCPACK(br0) 192.168.1.50 ce:92:d7:3b:bd:47 realme-9-Pro
Jun 27 20:17:19 kernel: wl0: random key value: D1821C746763188B67C10073583A708BE0BE9173138A0B84110A50362356B6DA
Jun 27 20:17:19 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jun 27 20:17:19 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: disassociated
Jun 27 20:17:20 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:20 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Unspecified reason (1)
Jun 27 20:17:20 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:20 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: associated
Jun 27 20:17:20 wlceventd: wlceventd_proc_event(534): eth6: Assoc CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:21 hostapd: eth6: STA ce:92:d7:3b:bd:47 RADIUS: starting accounting session 5D60AE20FABC0337
Jun 27 20:17:21 hostapd: eth6: STA ce:92:d7:3b:bd:47 WPA: pairwise key handshake completed (RSN)
Jun 27 20:17:21 dnsmasq-dhcp[3129]: DHCPREQUEST(br0) 192.168.1.50 ce:92:d7:3b:bd:47
Jun 27 20:17:21 dnsmasq-dhcp[3129]: DHCPACK(br0) 192.168.1.50 ce:92:d7:3b:bd:47 realme-9-Pro
Jun 27 20:17:23 kernel: wl0: random key value: 8ED856B9EEF9688402CF023F341FF24866F9766CDB0003C6972A0A9F0B802F04
Jun 27 20:17:23 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: disassociated
Jun 27 20:17:23 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jun 27 20:17:25 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:25 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: associated
Jun 27 20:17:25 wlceventd: wlceventd_proc_event(534): eth6: Assoc CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:25 hostapd: eth6: STA ce:92:d7:3b:bd:47 RADIUS: starting accounting session 46E8768F8D1CC600
Jun 27 20:17:25 hostapd: eth6: STA ce:92:d7:3b:bd:47 WPA: pairwise key handshake completed (RSN)
Jun 27 20:17:25 dnsmasq-dhcp[3129]: DHCPREQUEST(br0) 192.168.1.50 ce:92:d7:3b:bd:47
Jun 27 20:17:25 dnsmasq-dhcp[3129]: DHCPACK(br0) 192.168.1.50 ce:92:d7:3b:bd:47 realme-9-Pro
Jun 27 20:17:28 kernel: wl0: random key value: 8FEC09D9C206DB9224F703F4623D9BC63D20EFCB92A0059B1EE49E63E33AD5EE
Jun 27 20:17:28 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: disassociated
Jun 27 20:17:28 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jun 27 20:17:29 acsd: eth6: selected_chspec is 0x100b
Jun 27 20:17:29 acsd: eth6: Adjusted channel spec: 0x100b
Jun 27 20:17:29 acsd: eth6: selected channel spec: 0x100b
Jun 27 20:17:29 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:29 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: associated
Jun 27 20:17:29 wlceventd: wlceventd_proc_event(534): eth6: Assoc CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:34 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Previous authentication no longer valid (2)
Jun 27 20:17:34 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: disassociated
Jun 27 20:17:34 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind CE:927:3B:BD:47, status: 0, reason: Unspecified reason (1)
Jun 27 20:17:34 wlceventd: wlceventd_proc_event(505): eth6: Auth CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:34 wlceventd: wlceventd_proc_event(534): eth6: Assoc CE:927:3B:BD:47, status: Successful (0)
Jun 27 20:17:34 hostapd: eth6: STA ce:92:d7:3b:bd:47 IEEE 802.11: associated
Jun 27 20:17:34 hostapd: eth6: STA ce:92:d7:3b:bd:47 RADIUS: starting accounting session F2FB50F41522E76C
Jun 27 20:17:34 hostapd: eth6: STA ce:92:d7:3b:bd:47 WPA: pairwise key handshake completed (RSN)
Jun 27 20:17:34 dnsmasq-dhcp[3129]: DHCPREQUEST(br0) 192.168.1.50 ce:92:d7:3b:bd:47
Jun 27 20:17:34 dnsmasq-dhcp[3129]: DHCPACK(br0) 192.168.1.50 ce:92:d7:3b:bd:47 realme-9-Pro
Jun 27 20:17:35 dnsmasq-dhcp[3129]: DHCPREQUEST(br0) 192.168.1.50 ce:92:d7:3b:bd:47
Jun 27 20:17:35 dnsmasq-dhcp[3129]: DHCPACK(br0) 192.168.1.50 ce:92:d7:3b:bd:47 realme-9-Pro

 

[dave14305]

That's weird, I would expect it to behave similarly to IPv4 there. Worst case scenario I can always disable IPv6 support from Router mode I guess.

This kernel commit may be relevant, based on the call trace:

udp: properly support MSG_PEEK with truncated buffers - kernel/git/stable/linux.git - Linux kernel stable tree

git.kernel.org

But I’m too chicken to try to compile it.

 

[Akore]

Strange error and even stranger date showing on AC68U even after complete factory reset:

Jun 27 11:56:33 Mastiff: Got SIGTERM
Jun 27 11:56:33 Mastiff: Got SIGTERM
Jun 27 11:56:33 Mastiff: Got SIGTERM
Jun 27 11:56:34 Mastiff: Select error
May 5 00:05:14 Mastiff: init

 

[ZebMcKayhan]

I think this is related to the new IPv6 DNAT for DNS Filter.

rc: implement DNAT support for dnsfilter over IPV6 on HND models · RMerl/asuswrt-merlin.ng@c454668

Third party firmware for Asus routers (newer codebase) - rc: implement DNAT support for dnsfilter over IPV6 on HND models · RMerl/asuswrt-merlin.ng@c454668

github.com

I can recreate this by manually setting DNS on my iPad to Cloudflare IPv6 (2606:4700:4700::1112), having DNS Filter in Router mode, and then running the test at https://cmdns.dev.dns-oarc.net/

I imagine the rewrite of the udp ipv6 headers probably triggers this problem.

I've recently updated my rt-ac86u to 386.7 and been playing around with ipv6 DNAT (as implemented in Wireguard Manager). I've put all request to router (br0 ipv6) and performed a dns lookup from a client using both real and bogus ipv6 as dns and tracked the packages with tcpdump and all turned out translated properly and no errors in logs and a proper response was recieved. Shifted ipv6 DNAT to quad9 and did the same thing and all working properly and no errors in syslog.

Wonder why I dont see this issue? Perhaps because all my ipv6 goes out Wireguard instead of WAN (I dont have ipv6 WAN)? Naa, that can't be it.

 

[RMerlin]

This kernel commit may be relevant, based on the call trace:

udp: properly support MSG_PEEK with truncated buffers - kernel/git/stable/linux.git - Linux kernel stable tree

git.kernel.org

But I’m too chicken to try to compile it.

I did a quick search last night based on your stack trace, and saw a few kernel-related issues that might possibly be similar. However they were referring to kernel 4.19, while you are on 4.1.xx.

Worth a try to see if at least that patch can be applied to 4.1.xx. I'll need to find some spare time however to configure an IPv6 test setup, dunno when that will happen.

The patch is unlikely to cause a kernel crash at boot time (and worst case scenario recovery should be fairly easy if it does happen).

 

[RMerlin]

Strange error and even stranger date showing on AC68U even after complete factory reset:

Closed source component related to their AiHome service (I believe this is only available in Asia). Just ignore it.