Beta Asuswrt-Merlin 3004.388.4 beta is now available

[RMerlin]

I wonder if the repeated DDNS restarts I'm seeing only happen if the WAN reconnects AND the IPaddress is unchanged?

@alan6854321 , Yes. The "DDNS was updated" flag gets cleared when the connection goes down. When the update is triggered, the first update fails (probably due to timing), which triggers the watchdog retries. The pre-update checks determine that IP hasn't changed, and exits without setting the flag back to "updated", which causes the watchdog to keep retrying. That's at least the chain of event Asus could determine in their analysis of the issue, we'll know for sure once you test it with a fixed build.

 

[Jeff-Yeh]

Post #522: You said wifi is problem. Why are both radios turned off?
Also, turn off “Universal Beamforming”

Due to the same settings, there are no issues in 388.2_2, only in the Beta version. Moreover, it's not just the iPhone X; other devices like the Samsung S21 FE also experience this problem. Basically, even devices connected to the AX68U's WiFi encounter this issue.


But it seems like I'm the only one experiencing this issue, so I'll just let it go.

I'll wait for the next update and then give it another try.

 

[Mikeyy]

DDNS updating seams to work with latest Beta release. Didn't check logs if some errors are spamming them, but this morning IP was updated.
Need to check if I disabled router restarts when I get home.

Just checked logs from last 2 days, it seams ok! DDNS updated this morning without issues, and after this there was no DDNS logs whole day.

Aug 18 02:33:52 ddns: update CUSTOM , wan_unit 0
Aug 18 02:33:52 ddns: Clear ddns cache.
Aug 18 02:33:52 custom_script: Running /jffs/scripts/ddns-start (args: 123.456.789.001)
Aug 18 02:33:53 ddns: Completed custom ddns update

 

[RMerlin]

@alan6854321 , Yes. The "DDNS was updated" flag gets cleared when the connection goes down. When the update is triggered, the first update fails (probably due to timing), which triggers the watchdog retries. The pre-update checks determine that IP hasn't changed, and exits without setting the flag back to "updated", which causes the watchdog to keep retrying. That's at least the chain of event Asus could determine in their analysis of the issue, we'll know for sure once you test it with a fixed build.

Ok, try to reproduce the issue with this test build:

Microsoft OneDrive

1drv.ms

 

[alan6854321]

Ok, try to reproduce the issue with this test build:

@RMerlin - a quick test with RT-AX86U_3004_388.4_beta4-gd6af9f65e5_pureubi.w seems to indicate it's working fine.

NOTE - I haven't been able to test what happens when the IP address changes as I can't persuade my ISP to give me a new one at the moment.

After powering my modem off/on, the only syslog entry I can see relating to DDNS is...

Aug 18 16:58:59 ddns: WAN(0) IP is empty.(10)

 

[John Fitzgerald]

Due to the same settings, there are no issues in 388.2_2, only in the Beta version. Moreover, it's not just the iPhone X; other devices like the Samsung S21 FE also experience this problem. Basically, even devices connected to the AX68U's WiFi encounter this issue.


But it seems like I'm the only one experiencing this issue, so I'll just let it go.

I'll wait for the next update and then give it another try.

Despite my problem on my end, apologies for my faux pas, still: Disable - "Universal Beamforming".

 

[RMerlin]

After powering my modem off/on, the only syslog entry I can see relating to DDNS is...

Which is probably what originally triggered your issue - your WAN IP wasn't ready yet at the time the DDNS update was launched. I'll have to make sure it doesn't create any issue in cases where the IP does change.

NOTE - I haven't been able to test what happens when the IP address changes as I can't persuade my ISP to give me a new one at the moment.

It's ok, that's something I can test on my side since my PPPoE session causes my IP to change every time. I'll test that later tonight.

Thank you for the feedback. Let me know if anything unusual related to DDNS still happens over the next few days.

 

[octopus]

why skip event when trying to restart?

Aug 18 19:35:40 rc_service: service 17694:notify_rc restart_net_and_phy
Aug 18 19:35:40 rc_service: waitting "start_samba" via  ...
Aug 18 19:35:55 rc_service: skip the event: restart_net_and_phy.
Aug 18 19:36:53 rc_service: service 17911:notify_rc restart_wan_if
Aug 18 19:36:53 rc_service: waitting "start_samba" via  ...
Aug 18 19:37:08 rc_service: skip the event: restart_wan_if.
Aug 18 19:37:50 rc_service: service 18035:notify_rc restart_wan_if
Aug 18 19:37:50 rc_service: waitting "start_samba" via  ...
Aug 18 19:38:11 rc_service: service 18064:notify_rc restart_vpnclient1
Aug 18 19:38:11 rc_service: waitting "start_samba" via  ...
Aug 18 19:38:26 rc_service: skip the event: restart_vpnclient1.
Aug 18 19:50:37 rc_service: httpd 2818:notify_rc restart_wan_if 0;restart_stubby
Aug 18 19:50:37 rc_service: waitting "start_samba" via  ...
Aug 18 19:50:51 rc_service: skip the event: restart_wan_if 0;restart_stubby.
Aug 18 19:51:11 rc_service: httpd 2818:notify_rc restart_wan_if 0;restart_stubby
Aug 18 19:51:11 rc_service: waitting "start_samba" via  ...
Aug 18 19:51:26 rc_service: skip the event: restart_wan_if 0;restart_stubby.

 

[RMerlin]

why skip event when trying to restart?

Because your start_samba event took more than 30 seconds to complete, so queued events were skipped.

 

[octopus]

Because your start_samba event took more than 30 seconds to complete, so queued events were skipped.

okey got it, how to stop it?

 

[RMerlin]

okey got it, how to stop it?

If you have a plugged USB disk, you could try removing and putting it back. Otherwise, I'm not aware of any way to cancel a stuck event, so a reboot would be required. Asus made the whole event queue handling code closed source a couple of years ago.

 

[stef1949]

Ok, try to reproduce the issue with this test build:

Microsoft OneDrive

1drv.ms

Oooo rare Merlin easter egg build ~(˘▾˘~) ~(˘▾˘~) (joke)

 

[dbell]

Had this occur a couple of times today on my AX86U router, within about 7 mins of each other, and dumped back to login screen. This latest time I was refreshing the dhcp server page because it was not displayed properly.

Aug 18 12:44:10 dnsmasq-dhcp[1757]: DHCPREQUEST(br0) <ip> <mac> 
Aug 18 12:44:10 dnsmasq-dhcp[1757]: DHCPACK(br0) <ip> <mac> <hostname>
Aug 18 12:44:29 kernel: potentially unexpected fatal signal 11.
Aug 18 12:44:29 kernel: CPU: 0 PID: 12201 Comm: httpds Tainted: P           O    4.1.52 #2
Aug 18 12:44:29 kernel: Hardware name: Broadcom-v8A (DT)
Aug 18 12:44:29 kernel: task: ffffffc01bcccb40 ti: ffffffc02d174000 task.ti: ffffffc02d174000
Aug 18 12:44:29 kernel: PC is at 0x4e874
Aug 18 12:44:29 kernel: LR is at 0x4e838
Aug 18 12:44:29 kernel: pc : [<000000000004e874>] lr : [<000000000004e838>] pstate: 80030010
Aug 18 12:44:29 kernel: sp : 00000000ffc6eac0
Aug 18 12:44:29 kernel: x12: 00000000000c72c0
Aug 18 12:44:29 kernel: x11: 0000000000000001 x10: 00000000ffc6ed2b
Aug 18 12:44:29 kernel: x9 : 000000000048cdd0 x8 : 0000000000000000
Aug 18 12:44:29 kernel: x7 : 00000000ffc6ebe4 x6 : 00000000ffc6ed2e
Aug 18 12:44:29 kernel: x5 : 00000000f7429ab8 x4 : 0000000000000000
Aug 18 12:44:29 kernel: x3 : 00000000000a39df x2 : 000000000ba1ca00
Aug 18 12:44:29 kernel: x1 : 0000000000001039 x0 : 0000000000000000
Aug 18 12:44:46 watchdog: restart httpd
Aug 18 12:44:46 rc_service: watchdog 1778:notify_rc stop_httpd
Aug 18 12:44:46 rc_service: watchdog 1778:notify_rc start_httpd
Aug 18 12:44:46 RT-AX86U: start https:8443
Aug 18 12:44:46 RT-AX86U: start httpd:80
Aug 18 12:44:46 httpd: Save SSL certificate...80
Aug 18 12:44:46 httpd: mssl_cert_key_match : PASS
Aug 18 12:44:46 httpd: Succeed to init SSL certificate...80
Aug 18 12:44:46 httpd: Succeed to init SSL certificate...8443

 

[AmyGrrl]

Does 388.4 fix the issue with the 5Ghz Wifi dropping out randomly on the RT-AX88U? I had upgraded to 388.2 and had problems with the 5Ghz Wifi dropping randomly multiple times during the day. Ended up going back to 388.1 and the 5Ghz Wifi completely stopped dropping out. I never did try 388.2_2 was just going to wait for the next release. Will most likely wait until the final release of 388.4, but I'm curious to know if the 5Ghz Wifi issues are fixed.

 

[karateca]

Must to say yam impresive, for first time in 4 mouth dont disconnet from wan and its stable and fast. Evering work like a chart in this moment, 2 days with out PADO packets from wan.

 

[Jeff-Yeh]

Despite my problem on my end, apologies for my faux pas, still: Disable - "Universal Beamforming".

No worries , I was just curious why the same settings would cause issues when switching to the Beta version. Generally, 388.2_2 is quite stable. I've only encountered this problem with Beta 3. So, I'll wait and see how the next version performs before making a decision.

 

[Deleted member 77025]

Mine appears to be working okay.

View attachment 52362

Flashed the original ASUS Firmware and then the beta 3, working all fine again no issues so far.
All working smooth

 

[alan6854321]

Thank you for the feedback. Let me know if anything unusual related to DDNS still happens over the next few days.

@RMerlin - I restarted my modem this morning and it came back with a different IP address this time. The DDNS update went through straight away as expected.

Following entries in syslog -

Aug 19 11:15:49 WAN_Connection: WAN was restored.
Aug 19 11:15:49 ddns: update WWW.NO-IP.COM default@no-ip.com, wan_unit 0
Aug 19 11:15:49 ddns: Clear ddns cache.
Aug 19 11:15:49 ddns: Start Inadyn(10).
Aug 19 11:15:49 inadyn[21534]: In-a-dyn version 2.10.0 -- Dynamic DNS update client
Aug 19 11:15:49 inadyn[21534]: Update forced for alias xxxxxxxxxx.ddns.net, new IP# 51.999.999.999
Aug 19 11:15:50 inadyn[21534]: Updating cache for xxxxxxxxxx.ddns.net

 

[Ubimo]

My 5Ghz does not stay on channel 36.
After a reboot, my 5Ghz is always on channel 161, although I manually set it to 36.
Why?
Also, for extended channel, I cannot set "above" or "below". I have only "automatic" as an option.

Edit: Found the error, I forgot I had tinkered with init-start script.

 

[Salsoul]

Hi all,

Been a lurker for a while and loving the Asus WRT merlin work, been using it for a while on my GT-AX6000

But for me Im getting packet loss when using 3004.388. 4 Beta 2. I did a factory reset after installing and also tried dirty flash from offical 3.0.0.6.102_21514 to 3004.388. 4 Beta 2 still happening.

My connection is
Fibre > PPoE 900 mbps DL 900mbps UL
MTU set to 1492 everything else set to default

when gaming its laggy as hell on the 3004.388. 4 Beta 2 here is a pingtest to 1.1.1.1 100 times
View attachment 52332


for comparision here is the offical 3.0.0.6.102_21514 ran exactly 10 mins later

View attachment 52333

Any suggestions I much prefer to run Merlins build but unable to at the moment


Kind Regards

Sal

Thank you @RMerlin the latest beta has fixed my packetloss issue on the GT-AX6000