Release Asuswrt-Merlin 3004.388.10 is now available

[Pergola Fabio]

I have an ax-88u with this latest fw running, after a week or 2 , i see instabiliy issues in wifi ... they are dropping are reconnecting , a few hours later, internet is gone completely, not able to access the router anymore, not on cable/wifi , even on cable and define a static ip address..

when i look in log after a restart the router, i see some erros like:

...
Nov 28 13:10:14 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link UP at 1000 mbps full duplex
Nov 28 13:10:14 kernel: br0: port 3(eth3) entered forwarding state
Nov 28 13:10:14 kernel: br0: port 3(eth3) entered forwarding state
Nov 28 13:10:14 kernel: br1: port 4(eth3.501) entered listening state
Nov 28 13:10:14 kernel: br1: port 4(eth3.501) entered listening state
Nov 28 13:10:17 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link DOWN.
Nov 28 13:10:17 kernel: br0: port 3(eth3) entered disabled state
Nov 28 13:10:17 kernel: br1: port 4(eth3.501) entered disabled state
Nov 28 13:10:19 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) (phyId: a) Link UP at 1000 mbps full duplex
....
Nov 28 13:10:34 kernel: device br0 entered promiscuous mode
Nov 28 13:10:34 kernel: br1: port 4(eth3.501) entered learning state
...
Nov 28 13:10:49 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=14337
Nov 28 13:10:49 kernel: br1: topology change detected, sending tcn bpdu
Nov 28 13:10:49 kernel: br1: port 4(eth3.501) entered forwarding state

whats going on ? you can see its becoming instable, even the port is going down where my other ac86 node is connected with ..
what does this mean?

If i scroll up, the first time see the error, i also see some freed message?

Nov 28 12:55:04 wlceventd: wlceventd_proc_event(685): eth6: Auth D4:D2:D6:F5:FE:5A, status: Successful (0), rssi:0
Nov 28 12:55:04 wlceventd: wlceventd_proc_event(722): eth6: Assoc D4:D2:D6:F5:FE:5A, status: Successful (0), rssi:-82
Nov 28 12:55:04 hostapd: eth6: STA d4:d2:d6:f5:fe:5a IEEE 802.11: associated
Nov 28 12:55:04 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Nov 28 12:55:04 hostapd: eth6: STA d4:d2:d6:f5:fe:5a RADIUS: starting accounting session 7714E771AEAC6D9D
Nov 28 12:55:04 hostapd: eth6: STA d4:d2:d6:f5:fe:5a WPA: pairwise key handshake completed (RSN)
.....
Nov 28 12:55:08 kernel: FPM Pool 0: invalid token 0x04758000 freed
Nov 28 12:55:08 kernel: FPM Pool 0: ISR timer is enabled. There could be multiple occurrences of the reported issue
Nov 28 12:55:08 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1

 

[Cleanev]

RT-AX86U on 3004.388.10_2, with vnstat, YazDHCP, scMerlin & ntpMerlin add-ons

Finally configured ExpressVPN that works perfectly fine, however the VPN Status page does not show the Public IP address & instead just shows unknown for connected end-point (see snapshot)

VPN director is working as advertised and connections works fine. syslog shows correct Public IP address of the VPN end-point.

I have 2 AX-86U in a mesh configuration, so I pulled out mesh node and configured it from scratch; after adding VPN client, everything works fine & returns with ‘unknown’ as in the image. I switched with primary router and again configured it from scratch including ‘Restore’ from Administration, reset with WPS button and lastly installed ASUS official firmware and then upgraded to Merlin to get the same dreaded ‘unknown’ for Public IP.

Has anyone faced this situation and if any solution thereof?

Thanks you

 

[ColinTaylor]

RT-AX86U on 3004.388.10_2, with vnstat, YazDHCP, scMerlin & ntpMerlin add-ons

Finally configured ExpressVPN that works perfectly fine, however the VPN Status page does not show the Public IP address & instead just shows unknown for connected end-point (see snapshot)View attachment 69252

VPN director is working as advertised and connections works fine. syslog shows correct Public IP address of the VPN end-point.

I have 2 AX-86U in a mesh configuration, so I pulled out mesh node and configured it from scratch; after adding VPN client, everything works fine & returns with ‘unknown’ as in the image. I switched with primary router and again configured it from scratch including ‘Restore’ from Administration, reset with WPS button and lastly installed ASUS official firmware and then upgraded to Merlin to get the same dreaded ‘unknown’ for Public IP.

Has anyone faced this situation and if any solution thereof?

Thanks you

Can you SSH into the router and post the output from these command please. Change tun11 to be your OpenVPN interface name, e.g. tun11, tun12, tun13, etc.

/usr/sbin/ministun -t 5000 -c 1 -i tun11 stun.l.google.com:19302
/usr/sbin/curl -4 -m 5 -sf --interface tun11 api.ipify.org ; echo
nvram get vpn_stun

 

[Cleanev]

Can you SSH into the router and post the output from these command please. Change tun11 to be your OpenVPN interface name, e.g. tun11, tun12, tun13, etc.

/usr/sbin/ministun -t 5000 -c 1 -i tun11 stun.l.google.com:19302
/usr/sbin/curl -4 -m 5 -sf --interface tun11 api.ipify.org ; echo
nvram get vpn_stun

When run first time
1. 45.132.227.18
2. Just a blank line
3. No output

Restarted VPN using scmerlin
And here’s the output post restart
1. 172.98.32.68
2. Just a blank line
3. No output

Hope this helps.

 

[ColinTaylor]

When run first time
1. 45.132.227.18
2. Just a blank line
3. No output

Restarted VPN using scmerlin
And here’s the output post restart
1. 172.98.32.68
2. Just a blank line
3. No output
View attachment 69254

Hope this helps.

Thanks. I believe the router is now using the second command (curl) to determine the public IP address, but for some reason it isn't working. It should have returned the same address as the first command.

If you go to http://api.ipify.org/ in a browser (that's routed through the VPN) do you see the VPN's public IP address? How about http://ident.me/

Is this actually causing a problem or is it just a cosmetic issue?

 

[Cleanev]

Hi @ColinTaylor
Thank you for checking this. This is cosmetic issue as the data transfer is not hampered.

api.ipify.org - shows IP 172.98.32.68 on my iPad routed thru tunnel
ident.me - shows same IP - 172.98.32.68 But with a lot more information about the IP

 

[ColinTaylor]

Hi @ColinTaylor
Thank you for checking this. This is cosmetic issue as the data transfer is not hampered.

api.ipify.org - shows IP 172.98.32.68 on my iPad routed thru tunnel
ident.me - shows same IP - 172.98.32.68 But with a lot more information about the IP

OK thanks for the info. So it seems to be some sort of issue related to the router's curl command. I have no idea what that could be so I'll just leave it here and see if anyone else has some ideas.

EDIT: As your curl command didn't show any error messages could you run the command again without the -s flag and adding -v. That might generate some more information.

/usr/sbin/curl -4 -m 5 -vf --interface tun11 api.ipify.org ; echo

 

[Cleanev]

Unfortunately without ‘s’ it came up with a new error
curl: (6) name lookup timed out

 

[ColinTaylor]

Unfortunately without ‘s’ it came up with a new error
curl: (6) name lookup timed out

View attachment 69255

That's good. I don't think it's a new error, I think it was there before but just silenced with -s.

OK, so that suggests a possible DNS issue maybe. What WAN DNS servers are you using? What does this command return:

nslookup api.ipify.org

 

[Cleanev]

I am using self hosted unbound so it shows local IP 10.2.2.3 with that additional info for ipify.org
Server: 10.2.2.3
Address 1: 10.2.2.3 adtrap3

Name: api.ipify.org
Address 1: 104.26.12.205
Address 2: 104.26.13.205
Address 3: 172.67.74.152

 

[ColinTaylor]

Well the nslookup reply is correct so I can't think why curl appears to be timing out when resolving the same name.

Can you run the command again with the verbose flag, maybe that will show something:

/usr/sbin/curl -4 -m 5 -v --interface tun11 api.ipify.org ; echo

 

[Cleanev]

Oh boy - even though the previous command knows the destination address, this command with verbose output says a lot, I guess.

* name lookup timed out
* Could not resolve host: api.ipify.org
* Closing connection
curl: (6) name lookup timed out

I figured to check with this command
/usr/sbin/curl -v --interface tun11 api.ipify.org ; echo

* Trying 104.26.12.205:80...
* socket successfully bound to interface 'tun11'
* Connected to api.ipify.org (104.26.12.205) port 80
> GET / HTTP/1.1
> Host: api.ipify.org
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 30 Nov 2025 02:35:28 GMT
< Content-Type: text/plain
< Content-Length: 12
< Connection: keep-alive
< Server: cloudflare
< Vary: Origin
< cf-cache-status: DYNAMIC
< CF-RAY: 9a66f39d880a4ba9-IAD
<
* Connection #0 to host api.ipify.org left intact
172.98.32.68

 

[ColinTaylor]

That's very strange. As a sanity check can you verify the contents of resolv.conf

cat /etc/resolv.conf

 

[Cleanev]

Yes as I stated earlier, there are two DNS (unbound) hosted on LAN and that’s the IPs that are reflected in resolv.conf

nameserver 10.2.2.3
nameserver 10.2.2.4

 

[ColinTaylor]

Yes as I stated earlier, there are two DNS (unbound) hosted on LAN and that’s the IPs that are reflected in resolv.conf

nameserver 10.2.2.3
nameserver 10.2.2.4

Is it possible that your Unbound server really is taking more than 5 seconds to reply?

Try changing the curl timeout to 15 seconds:

/usr/sbin/curl -4 -m 15 -v --interface tun11 api.ipify.org ; echo

 

[Cleanev]

Is it possible that your Unbound server really is taking more than 5 seconds to reply?

Try changing the curl timeout to 15 seconds:

/usr/sbin/curl -4 -m 15 -v --interface tun11 api.ipify.org ; echo

* Trying 104.26.12.205:80...
* socket successfully bound to interface 'tun11'
* Connected to api.ipify.org (104.26.12.205) port 80
> GET / HTTP/1.1
> Host: api.ipify.org
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 30 Nov 2025 02:47:24 GMT
< Content-Type: text/plain
< Content-Length: 12
< Connection: keep-alive
< Server: cloudflare
< Vary: Origin
< cf-cache-status: DYNAMIC
< CF-RAY: 9a6705181f24c655-IAD
<
* Connection #0 to host api.ipify.org left intact
172.98.32.68




I tried ‘dig’ command and got this output
; <<>> DiG 9.20.7 <<>> +noidnin +noidnout api.ipify.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20696
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 3 (Stale Answer)
;; QUESTION SECTION:
;api.ipify.org. IN A

;; ANSWER SECTION:
api.ipify.org. 0 IN A 104.26.13.205
api.ipify.org. 0 IN A 104.26.12.205
api.ipify.org. 0 IN A 172.67.74.152

;; Query time: 3 msec
;; SERVER: 10.2.2.4#53(10.2.2.4) (UDP)
;; WHEN: Sat Nov 29 21:46:03 EST 2025
;; MSG SIZE rcvd: 96

 

[ColinTaylor]

* Trying 104.26.12.205:80...
* socket successfully bound to interface 'tun11'
* Connected to api.ipify.org (104.26.12.205) port 80
> GET / HTTP/1.1
> Host: api.ipify.org
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 30 Nov 2025 02:47:24 GMT
< Content-Type: text/plain
< Content-Length: 12
< Connection: keep-alive
< Server: cloudflare
< Vary: Origin
< cf-cache-status: DYNAMIC
< CF-RAY: 9a6705181f24c655-IAD
<
* Connection #0 to host api.ipify.org left intact
172.98.32.68




I tried ‘dig’ command and got this output
; <<>> DiG 9.20.7 <<>> +noidnin +noidnout api.ipify.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20696
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 3 (Stale Answer)
;; QUESTION SECTION:
;api.ipify.org. IN A

;; ANSWER SECTION:
api.ipify.org. 0 IN A 104.26.13.205
api.ipify.org. 0 IN A 104.26.12.205
api.ipify.org. 0 IN A 172.67.74.152

;; Query time: 3 msec
;; SERVER: 10.2.2.4#53(10.2.2.4) (UDP)
;; WHEN: Sat Nov 29 21:46:03 EST 2025
;; MSG SIZE rcvd: 96

Perhaps you could temporarily change your WAN DNS servers to something like 1.1.1.1 or 8.8.8.8 and see if you have the same (-m 5) timeout problem?

 

[Cleanev]

Perhaps you could temporarily change your WAN DNS servers to something like 1.1.1.1 or 8.8.8.8 and see if you have the same (-m 5) timeout problem?

I managed to change WAN DNS around 1am so as not to face WAF
It worked right away showing IP instead of unknown. I started to question why either of the unbound may be taking 5+ seconds to respond so diving deeper, found that 10.2.2.3 was throwing all kinds of errors and running “curl -4 -m 15 -v --interface eth0 api.ipify.org ; echo” will return errors communicating at 127.0.0.1:5335.

Long story short - rebuilt both from scratch using Trixie (replacing bookworm). Slept a few hours and finished configuring router from scratch one more time and all seems to be functional.

Seems nvram setting vpn_stun does not exist and therefore is showing nothing.

@ColinTaylor - I very much appreciate your assistance, your knowledge helped me learn a lot more. Thank you for your patience and guidance. Happy holidays.

 

[Reef2009]

Hi,
I use Wake-on-LAN occasionally. I recently noticed that it doesn't work via the web interface, but it does work via the ASUS Router app.
Is this a known issue and i think its easy to fix? Perhaps something for the .11 update?

 

[rung]

Hi,
I use Wake-on-LAN occasionally. I recently noticed that it doesn't work via the web interface, but it does work via the ASUS Router app.
Is this a known issue and i think its easy to fix? Perhaps something for the .11 update?

Try "ether-wake -b -i br0 <MAC address>" which is the command executed on the WOL page.

Note that command doesn't work with my PC. I need to remove the "-b" for it to wake up.