Beta Asuswrt-Merlin 388.2 Beta is now available for Wifi 6 models

[DiGz_Au]

View attachment 49008

10 days for Beta and no issues observered here, hence, the most stable beta in months...
I believe the latest GPL has improved WIFI stabillity, maybe just an illustion, anyway- Im good with that

36/160MHZ dropped to 44/80Mhz when DFS was idle (just noticed today- it caused some IOT devices to connect-disconnect untill they just disoconnect) , had to change to Auto/160Mhz, which picked 44/160, manually changed to 44/160 which dropped back to 36/160 so I manually changed it to 36/160 again (like in the beginning), like a set- and re-set kind of thing, and for a few hours it looks fine,
Will keep looking in the next 48h when flights are back to operate, as there is a flight-route over my head- 6 days a week.

388 is just poor for WiFi 6 on ax86u. I can go back and forwards between 386.5-2 and 388.1 or 2 and my wifi devices show loads of resent packets on diagnostic tests. 386-5-2 is the last firmware I can use that our s22s and s23s wifi 6 actually works stable.
Edit:
I've change the country code to Australia as it should be since it reverts to Asia (default). I'm just confused as to why this is going on. Will sub this router out very soon I think. It's a shame really.

 

[RMerlin]

Discussions about 160 MHz channel usage moved to a separate thread. Let's get back on topic here.

On this note, since OpenVPN 2.6.2 introduced a significant memory leak fix, I decided to update it, and go through a second beta cycle, and to take advantage of it to also proceed with a few other changes (like updating curl to the latest version, as recent releases included a number of CVE-related fixes, and I didn`t feel like analyzing them one by one to determine if any of them was critical). These changes are significant enough to warrant another beta cycle. I expect to have beta 2 builds ready over the coming days.

 

[Dedel66]

I'am ready to test!

 

[Hawk]

Merlin I was trying firmware on RT-AX88U Pro and noticed after factory reset under wireless professional tab roaming assist was set to -70, from what I can remember your firmware always disabled it, while original asus firmware left it on. I could be mistaken but is it possible to have default to disable or is it closed source component.

 

[Kyjiep]

I think i figured it out, in the process of updates to the firmware and reseting the router i think i forgot to disable the option Spanning-Tree Protocol, still not sure if its completly solved, but i made a quick test and it looks that with this disable the static entry stays configured.

Feel free to try.

View attachment 48990

This method did not help me. As before, after installing beta1, a static entry in the ARP lives only about 5 minutes. I returned to alpha1 again - everything works as it should in it.

 

[shabbs]

I expect to have beta 2 builds ready over the coming days.

Let's GO!

 

[PDinDetroit]

I dirty updated from 386.5_2 to 388.2 Beta 1 about 1 week ago. Only issue has been free memory slowly goes down over time without being in the UI (looking at memory usage in the UI). If I reload the blocking list in Diversion, the memory goes back to about 51-53% but will be back up again within about 6-8 hours. I let it go for 4 days and the internet connection was still working fine, but the router UI would only show 13 clients when there were somewhere around 30 clients.

I decided today to uninstall Diversion, update Entware packages, and reinstall Diversion. We'll see where it gets to tomorrow sometime. I may reset the 3 routers in the house and reconfigure once Beta 2 come out.

Thank you again Merlin for all your hard work.

 

[SomeWhereOverTheRainBow]

Discussions about 160 MHz channel usage moved to a separate thread. Let's get back on topic here.

Thank you.

 

[RMerlin]

I could be mistaken but is it possible to have default to disable or is it closed source component.

I reverted to the default stock value to avoid potential issues with AiMesh (which probably expects that to be enabled).

 

[snapieee]

Upgraded gt-ax6000 to beta 1 from alpha 1 and i am seeing the following lines in the log every time i visit the adaptive qos page:

Apr  1 23:01:08 kernel: Init chrdev /dev/idp with major 190
Apr  1 23:01:08 kernel: tdts: tcp_conn_max = 8000
Apr  1 23:01:08 kernel: tdts: tcp_conn_timeout = 300 sec
Apr  1 23:01:10 kernel: SHN Release Version: 2.0.6 9d6bb506
Apr  1 23:01:10 kernel: UDB Core Version: 0.2.20
Apr  1 23:01:10 kernel: Init chrdev /dev/idpfw with major 191
Apr  1 23:01:10 kernel: Registered DNS Req parsing
Apr  1 23:01:10 kernel: IDPfw: flush fc
Apr  1 23:01:10 kernel: IDPfw: IDPfw is ready
Apr  1 23:01:10 kernel: sizeof forward pkt param = 280
Apr  1 23:01:10 BWDPI: fun bitmap = 3
Apr  1 23:01:24 BWDPI: force to flush flowcache entries
Apr  1 23:01:24 kernel: IDPfw: Exit IDPfw
Apr  1 23:01:24 kernel: mod epilog takes 0 jiffies
Apr  1 23:01:24 kernel: IDPfw: Exit IDPfw
Apr  1 23:01:24 kernel: Exit chrdev /dev/idpfw with major 191
Apr  1 23:01:24 kernel: udb_core lock_num = 16
Apr  1 23:01:24 kernel: Exit chrdev /dev/idp with major 190
Apr  1 23:01:24 BWDPI: rollback fc
Apr  1 23:34:54 rc_service: service 12313:notify_rc restart_dnsmasq
Apr  1 23:34:54 custom_script: Running /jffs/scripts/service-event (args: restart dnsmasq)
Apr  1 23:34:54 custom_config: Appending content of /jffs/configs/dnsmasq.conf.add.
Apr  1 23:34:54 custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf)
Apr  1 23:34:54 Diversion: restarted Dnsmasq to apply settings
Apr  1 23:34:54 stubby[12767]: Stubby version: Stubby 0.4.2
Apr  1 23:34:54 custom_script: Running /jffs/scripts/service-event-end (args: restart dnsmasq)
Apr  1 23:01:24 custom_script: Running /jffs/scripts/nat-start
Apr  1 23:01:24 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Apr  1 23:35:13 Skynet: [i] Mounting Skynet Web Page As user4.asp

I initially saw the those entries in the log while i was on 388.1_0 but once upgraded to alpha 1 they were gone. I never saw those entries while on alpha 1, except there were no throughput is being displayed. So, i remained on that version until a new release. When beta 1 was released i had high hopes so i moved to that version but unfortunately issue came back again. I tried to downgrade to alpha 2 and i am still seeing same lines any time i go to the qos page. I don't have any of the trendmicro stuff enabled.

edit: Sometimes I open another tab to display the log and another where i go to the qos page i see the same lines above in addition to the following:

Apr  1 23:43:29 kernel: potentially unexpected fatal signal 11.
Apr  1 23:43:29 kernel: CPU: 1 PID: 27452 Comm: dcd Tainted: P           O      4.19.183 #1
Apr  1 23:43:29 kernel: Hardware name: GTAX6000_50991 (DT)
Apr  1 23:43:29 kernel: pstate: 200f0010 (nzCv q A32 LE aif)
Apr  1 23:43:29 kernel: pc : 00000000f7c6c9d8
Apr  1 23:43:29 kernel: lr : 0000000080808080
Apr  1 23:43:29 kernel: sp : 00000000ffc82820
Apr  1 23:43:29 kernel: x12: 0000000000000000
Apr  1 23:43:29 kernel: x11: 0000000000000000 x10: 000000000007e66c
Apr  1 23:43:29 kernel: x9 : 00000000f6eef008 x8 : 00000000000a387e
Apr  1 23:43:29 kernel: x7 : 0000000000000010 x6 : 0000000000000000
Apr  1 23:43:29 kernel: x5 : 00000000000a3884 x4 : 00000000fefefeff
Apr  1 23:43:29 kernel: x3 : 0000000000000000 x2 : 0000000000000000
Apr  1 23:43:29 kernel: x1 : 0000000000000107 x0 : 0000000000000000

But the weird thing here, is that i can see some throughput.....!!!!!!



Another issue i have is the same issue that other reported where they don't see any throughput under adaptive qos. I never had this issue before and i never had to enable app analysis in order to see any throughput. One more issue is that whenever i go to the aimesh page the link between the nodes gets cut like this:

If i move to any another page such as Tools and navigated back to aimesh page again, waited about 2 min the full link line gets displayed properly. Also, if i remained under the aimesh page but clicked on any nodes the issue comes back again.

I tried clearing cache and cookies, even used different browsers but this aimesh issue remains visible.

As stated earlier i don't have any of the trendmicro stuff enabled. I am only running the following scripts: Diversion, Skynet, scMerlin, YazDHCP. I also tried a clean install without any scripts, just the firmware, and still experiencing same issues.

Edit: If I downgraded to alpha 1, I don't experience any issue except the one where I don't see any throughput under qos page.

 

[RMerlin]

and i am seeing the following lines in the log every time i visit the adaptive qos page:

Nothing abnormal there.

Sometimes I open another tab to display the log and another where i go to the qos page i see the same lines above in addition to the following:

dcd crashing is a well known issue that has been there for years, and Trend Micro doesn't seem to care enough to fix it.

Another issue i have is the same issue that other reported where they don't see any throughput under adaptive qos.

As mentioned a number of times already, you have to enable Apps Analysis.

 

[Meanshadows35]

11 days on 388.2 beta on the RTAX68U has been rock solid.

 

[MilkyOneWay]

This method did not help me. As before, after installing beta1, a static entry in the ARP lives only about 5 minutes. I returned to alpha1 again - everything works as it should in it.

You are right, after further testing it didn't work here too...
I reverted to the 388.1, i try to mess a bit with arp things in linux, but i'm kinda noob... if it's not fixed on 388.2 i will stay in this version.

 

[iBest]

You intend to release Beta 2 or the final release will follow beta 1?
Thank you very much

 

[Dedel66]

You intend to release Beta 2 or the final release will follow beta 1?
Thank you very much

Read post #342...

 

[Zork]

I have 2 ax86u, one on mesh. Over serveral month staying with 386.7_2, if flash to 388 beta 1 or someday more beta 2.

Will need a factory reset and clean install o can use dirty flash ?

 

[ElmerFudd]

I have 2 ax86u, one on mesh. Over serveral month staying with 386.7_2, if flash to 388 beta 1 or someday more beta 2.

Will need a factory reset and clean install o can use dirty flash ?

I got bit with the dirty upgrade for the 388.2 beta and for some reason my Adguard Home would no longer start and I could not fix not matter what I did (spent hours in forums). However, others reported no problems and I have dirty upgraded in the past no problems.

The one thing I discovered is a clean install is not that hard If you backup the router settings first. To fix my Adguard, I just did a factory reset, restored backup of cfg file, redid the swap file, reinstalled and configured AMTM packages, …. Took me about 30 min.

 

[snapieee]

Nothing abnormal there.


dcd crashing is a well known issue that has been there for years, and Trend Micro doesn't seem to care enough to fix it.


As mentioned a number of times already, you have to enable Apps Analysis.

Thank you

 

[John Fitzgerald]

Discussions about 160 MHz channel usage moved to a separate thread. Let's get back on topic here.

On this note, since OpenVPN 2.6.2 introduced a significant memory leak fix, I decided to update it, and go through a second beta cycle, and to take advantage of it to also proceed with a few other changes (like updating curl to the latest version, as recent releases included a number of CVE-related fixes, and I didn`t feel like analyzing them one by one to determine if any of them was critical). These changes are significant enough to warrant another beta cycle. I expect to have beta 2 builds ready over the coming days.

Will the new beta incorporate the new AMTM version 3.5?

 

[JGrana]

Mounting cifs shares doesn't appear to be working with 388.2_b1 on AX88U Pro's.

Here is the mount command:

/bin/mount -v \\\\192.168.1.211\\Multimedia /tmp/mnt/HomerNAS -t cifs -o vers=2.1,user=admin,password=xxxxxxx

On an AX86U running either 386.7_2 or 388.2_beta1, the mount does fine.
On an AX88U Pro running 388.2_beta1 - it fails to mount with this error:

mount: mounting \\192.168.1.211\Multimedia on /tmp/mnt/HomerNAS failed: Permission denied

dmesg shows:

Status code returned 0xc000006d STATUS_LOGON_FAILURE
Status code returned 0xc000006d STATUS_LOGON_FAILURE

I did see that the kernel version on the AX86U is 4.1.52 and on the AX88U Pro it's 4.19.182

Both routers mount command are linked to busybox.
The busybox version (1.25.1) is the same on both routers.

Maybe a kernel issue?