Release Asuswrt-Merlin 388.2 is now available for select models

[jmat]

To the attention of all those whose static entry in the ARP is dying after the update to the 388.2 release. Today I conducted another experiment - I reset the router to factory settings before updating from 388.2alpha1 to 388.2release, after the update I made only the initial configuration and again reset to factory settings with a checkmark in the checkbox, after that I once again performed only the initial configuration of the router and did another reset to factory settings, but without a checkmark in the checkbox. After that, I made the initial configuration of the router and created a static entry in the ARP, and this entry has been working for 1 hour. After my previous repeated attempts to update, the static entry in the ARP disappeared 3-8 minutes after it was created. I don't know what exactly brought success this time, maybe it's just a matter of chance, maybe not quite a chance, I think you should try it.

P.S.:
And still the bug remained, I just noticed that the static entry in ARP does not disappear if it is created for an IP that is not on the same subnet as the router. For example: the address of the router is 192.168.50.1. If a static entry is created for ip 192.168.1.254, then it lives for an arbitrarily long time, until the router is rebooted. If you create a static entry for ip 192.168.50.254, then in most cases it dies after 5-10 minutes, but occasionally it lives much longer, until the router is rebooted. I will look and try different options further.

P.P.S.:
It seems I have found a crutch with which the desired static entry survives.
So: the ip of the router is 192.168.50.1, it is necessary that the static entry (192.168.50.254) at ff:ff:ff:ff:ff:ff does not die.
Create a services-start script with the following content:

#!/bin/sh
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.50.254 ff:ff:ff:ff:ff:ff

Entries in the script should only be in that order.
We reboot the router.
The presence of an entry (192.168.1.254) at ff:ff:ff:ff:ff:ff prevents the death of an entry (192.168.50.254) at ff:ff:ff:ff:ff:ff.
Checked 5 times in a row - the static entry (192.168.50.254) at ff:ff:ff:ff:ff:ff does not die.

P.P.P.S.:
Today I discovered that this method does not always work (((.

Thank you very much for your effort proposing this solution. At least in my case it is currently working on an AX86U router with version 388.2, but I will continue to report in the coming days on whether the permanence of the broadcast IP is really maintained. All the best,

 

[Bogey]

388.2 has a newer version of dnsmasq.

So this version of dnsmasq results in combination with Skynet and/or(?) Diversion is what's causing the problems with our routers?
The solution is either a) abort Skynet and/or(?) Diversion or b) wait until an update for Skynet and/or Diversion arrives or c) get a more powerful router?

 

[bluepoint]

So this version of dnsmasq results in combination with Skynet and/or(?) Diversion is what's causing the problems with our routers?
The solution is either a) abort Skynet and/or(?) Diversion or b) wait until an update for Skynet and/or Diversion arrives or c) get a more powerful router?

Diversion works fine with this dnsmasq version here. If you're having problem with both skynet and diversion then it points to your usb stick. Try another usb starting from scratch.

 

[sweetlyham]

I need some help with a 5Ghz wireless issue I have on my RT-AX58U router. When I use the 388.2 firmware and set the region to Australia under Wireless > Professional, the 5Ghz channel has no throughput. This was not a problem on the 388.1 firmware, where the 5Ghz channel worked fine with Auto channel and DFS enabled.

These are the settings I used for testing, changing only the region. The 5Ghz channel works when the region is set to ‘Asia (Default)’, but not when it is set to ‘Australia’.

I have tried a hard WPS reset on both 388.1 and 388.2 firmware, and also restored factory default settings, but the issue remains. I think this is more than a coincidence that the 5Ghz channel stops working when I switch to the Australian region.

Update 1:

I had an idea after posting this: I disabled all the settings that had an Enable/Disable option under Wireless > Professional, and the 5Ghz channel worked when the region was set to Australia. I will try turning them on one by one to see which one affects the throughput.

Update 2:

After re-enabling the different settings under Wireless > Professional, the 5Ghz throughput with region set to Australia is still working, which is annoying! I will need to monitor it now.

 

[RMerlin]

So this version of dnsmasq results in combination with Skynet and/or(?) Diversion is what's causing the problems with our routers?

Maybe. I'm just pointing out to one specific change that might explain the behaviour difference between 388.1 and 388.2, and would also tie three of the four reported issues together.

 

[Bogey]

Diversion works fine with this dnsmasq version here. If you're having problem with both skynet and diversion then it points to your usb stick. Try another usb starting from scratch.

The USB was new, one of the better tested long lasting ones and it’s in USB2 mode. But more so because, as reported, there’s no problem with 388.1 Even going back “dirty” from .2 to .1 solves it. I doubt the USB is the culprit, but… one can only know for certain after having tested it.

Maybe. I'm just pointing out to one specific change that might explain the behaviour difference between 388.1 and 388.2, and would also tie three of the four reported issues together.

Ok. Unfortunately it will have to wait for Tuesday for me to test, then I have the opportunity to test it without bothering my family.

 

[Quoc Huynh]

I need some help with a 5Ghz wireless issue I have on my RT-AX58U router. When I use the 388.2 firmware and set the region to Australia under Wireless > Professional, the 5Ghz channel has no throughput. This was not a problem on the 388.1 firmware, where the 5Ghz channel worked fine with Auto channel and DFS enabled.

These are the settings I used for testing, changing only the region. The 5Ghz channel works when the region is set to ‘Asia (Default)’, but not when it is set to ‘Australia’.

I have tried a hard WPS reset on both 388.1 and 388.2 firmware, and also restored factory default settings, but the issue remains. I think this is more than a coincidence that the 5Ghz channel stops working when I switch to the Australian region.

View attachment 49755
View attachment 49756

Update 1:

I had an idea after posting this: I disabled all the settings that had an Enable/Disable option under Wireless > Professional, and the 5Ghz channel worked when the region was set to Australia. I will try turning them on one by one to see which one affects the throughput.

View attachment 49757

Update 2:

After re-enabling the different settings under Wireless > Professional, the 5Ghz throughput with region set to Australia is still working, which is annoying! I will need to monitor it now.

I am in Canberra - Australia, and the 5Ghz on the RT-AX88U, 388.2 firmware works fine for me, regardless of regions or enabling DFS channels. I also did a hard reset before and after upgrading as there was a weird issue with my attached USB drive.

 

[sweetlyham]

I am in Canberra - Australia, and the 5Ghz on the RT-AX88U, 388.2 firmware works fine for me, regardless of regions or enabling DFS channels. I also did a hard reset before and after upgrading as there was a weird issue with my attached USB drive.

It seems that turning off and on the relevant settings under the professional tab has solved the problem, as it has been working well so far.

 

[Quoc Huynh]

It seems that turning off and on the relevant settings under the professional tab has solved the problem, as it has been working well so far.

It's great to know that your wifi is working ok. Sorry I just remember that turning on DFS channels in 5Ghz gave me intermittent drops. Thus I have to disable it for a more stable connection.

 

[spykos]

How did you get the region setting in the Professional section of Wireless page ? in AX86U there is no such entry.

 

[clweb]

How did you get the region setting in the Professional section of Wireless page ? in AX86U there is no such entry.

On my AX58U I have also no such entry, but all works good. 5 GHz with 160Mhz BW no problem here. Channel 100 is configured.

 

[jmat]

How did you get the region setting in the Professional section of Wireless page ? in AX86U there is no such entry.

I don't have any problem with the wireless, but I also don't have any option to select the region in the Professional section of my router purchased in the EU. All the best,

 

[Quoc Huynh]

How did you get the region setting in the Professional section of Wireless page ? in AX86U there is no such entry.

As I know, it depends on where routers are intended to sold, and when they are manufactured. I bought my AX88U, which is made in China, in Australia in 2020, and it has regional setting in the Advance Wireless section. However, some routers bought recently does not have that option, probably due to recent changes in government requirement.

 

[Ubimo]

I just got this in syslog, following a skynet outage/restart.

May  1 10:28:12 kernel: SHN Release Version: 2.0.1 21224-01
May  1 10:28:12 kernel: UDB Core Version: 0.2.20
May  1 10:28:12 kernel: Registered DNS Req parsing
May  1 10:28:12 kernel: sizeof forward pkt param = 280
May  1 10:28:45 kernel: udb_core lock_num = 9
May  1 10:28:46 kernel: DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:e4:8d:8c:ac:4a:fc:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=135 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=5678 DPT=5678 LEN=115 MARK=0x8000000
May  1 10:28:46 kernel: DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:2c:c8:1b:5f:fd:48:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=16 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308 MARK=0x8000000
May  1 10:28:46 kernel: DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:cc:2d:e0:0f:1a:48:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=144 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=5678 DPT=5678 LEN=124 MARK=0x8000000
May  1 10:28:46 kernel: DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:e4:8d:8c:e2:8a:96:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=5678 DPT=5678 LEN=116 MARK=0x8000000
May  1 10:28:48 kernel: DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:2c:c8:1b:5f:fd:48:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=16 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308 MARK=0x8000000
May  1 10:28:54 kernel: DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:2c:c8:1b:5f:fd:48:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=16 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308 MARK=0x8000000

 

[plexion]

I am seeing some weird CPU usage issues after upgrading to 388 from 386.7_2 on my Asus RT-AX56U.
I have tried 388.1, 388.2 Beta and now 388.2, all resulting in the same outcome.

Issues:
1. Only 3 out of 4 CPU cores of the router is utilized. 4th core is always idle.
2. Higher than usual CPU usage on 388 firmwares compared to 386.7_2 constantly, even on idle. The "sysstate" process using up quite a lot of CPU time.


CPU Usage Graph on 388.2

View attachment 49449


CPU Usage Graph on 386.7_2

View attachment 49450


Top Command Output on 388.2

View attachment 49453


Top Command Output on 386.7_2

View attachment 49454

I have tried:
1. Dirty flashing from 386.7_2 to the 388 series firmwares.
2. Factory reset on 386.7_2, then flashing to 388 series firmwares.
3. Factory reset on 388 series firmwares after upgrading from 386.7_2.

All outcome are the same as above.

Going back to 386.7_2 also always resolves the problem.

Appreciate if anyone can help to shed some light on the behaviours of the router above.
Thanks!

Anyone able to help or was able to find a fix with the issue above?
Or I would have to keep my AX56U on 386.7_2?

Thank you

 

[saison2023]

The USB was new, one of the better tested long lasting ones and it’s in USB2 mode. But more so because, as reported, there’s no problem with 388.1 Even going back “dirty” from .2 to .1 solves it. I doubt the USB is the culprit, but… one can only know for certain after having tested it.


Ok. Unfortunately it will have to wait for Tuesday for me to test, then I have the opportunity to test it without bothering my family.

I am not able to test it right now, but I saw that AMTM and Diversion were not "up to date".
I will update all the packages, let them run a little bit on 388.1 and will upgrade to 388.2.
Will post the result of my tests in the following days.

 

[stevieosaurus]

Everything running smooth, thank you @rmerlin.10954 !

Q: is there a possibility to expand to more than 5 WireGuard connections set in the VPN client (& VPN director) list, perhaps in a future update, or is this something only ASUS can do in their base GUI ?

 

[Jumpstarter]

Just switched to RMerlin on the RT-AX88U-PRO, factory reset and everything. Now I am stuck in a forever configuration loop...

what the heck is going on?

I get stuck on this page

 

[John Fitzgerald]

Just switched to RMerlin on the RT-AX88U-PRO, factory reset and everything. Now I am stuck in a forever configuration loop...
View attachment 49857

what the heck is going on?

I get stuck on this page

View attachment 49858

Tried “Electrical Reset”?

 

[Weblee2407]

Updated to 388.2 over the weekend, and it seems I got some type of driver error early this morning - it generated a dump to screen and didn't reboot the router.

May 3 01:41:56 irongate kernel: bcm63xx_nand ff801800.nand: program failed at 8340600
May 3 01:41:56 irongate kernel: ubi0 error: ubi_io_write: error -5 while writing 2048 bytes to PEB 1034:0, written 0 bytes
May 3 01:41:56 irongate kernel: CPU: 2 PID: 118 Comm: ubi_bgt0d Tainted: P O 4.19.183 #1
May 3 01:41:56 irongate kernel: Hardware name: GTAX6000_50991 (DT)
May 3 01:41:56 irongate kernel: Call trace:
May 3 01:41:56 irongate kernel: dump_backtrace+0x0/0x150
May 3 01:41:56 irongate kernel: show_stack+0x14/0x20
May 3 01:41:56 irongate kernel: dump_stack+0x94/0xc4
May 3 01:41:56 irongate kernel: ubi_io_write+0x574/0x690
May 3 01:41:56 irongate kernel: ubi_io_write_ec_hdr+0xc4/0x110
May 3 01:41:56 irongate kernel: sync_erase.isra.0+0x11c/0x1f0
May 3 01:41:56 irongate kernel: __erase_worker+0x34/0x460
May 3 01:41:56 irongate kernel: erase_worker+0x18/0x80
May 3 01:41:56 irongate kernel: do_work+0x98/0x120
May 3 01:41:56 irongate kernel: ubi_thread+0x108/0x190
May 3 01:41:56 irongate kernel: kthread+0x118/0x150
May 3 01:41:56 irongate kernel: ret_from_fork+0x10/0x24
May 3 01:41:56 irongate kernel: ubi0: dumping 2048 bytes of data from PEB 1034, offset 0

Can anyone tell me what is at issue here?