Release Asuswrt-Merlin 388.1 is now available for all supported Wifi 6 models

[CaptainSTX]

I usually do it, but I have a lot of data to be entered (specially the DHCP reservations), so from time to time I only do a dirty update. Anyway, I will probably wait until the next FW, because apart from that glitch, it is working well.

I have rebooted just know (I have all people outside home ) and it works well again. If some one knows how to restart this service without rebooting, it would be good for now ...

You should consider adding the script YazDHCP. It allows you so save to CSV file a list of your assigned static IPs and the associated MAC. It then makes it possible to reload this information on any router with this utility loaded. The only information you lose is the ICON representing the particular device. Makes a factory reset much less painful for people that use numerous static IPs.

 

[snapieee]

I recently got the gt-ax6000 and installed 388.1. I let the router run for a couple of days without any scripts nor any of the trendmicro stuff enabled. I just did the basic setup and added two aimesh nodes (gt-ax6000 is the main and two rt-ac68u nodes). Once I confirmed router is stable, I started installing/enabling some scripts via amtm (Diversion, Skynet, scMerlin, YazDHCP). Router remained stable for a couple of weeks without any single issue. The only thing that I noticed happening was seeing this error “kernel: Init chrdev /dev/idp with major 190” in the log whenever I navigate to the Adaptive QoS page, confirmed this by reading some previous posts in this forum.

A couple of days ago I decide to enable QoS since I started having issues with my voip service at home, which I didn’t have when I had my trusty rt-ac68u, but I keep getting this error in the log: BWDPI: module is blocked, reason=1. I tried turning qos off, reboot and re-enable qos again but I am still seeing the same error. Currently, QoS is off, none of the trendmicro stuff are enabled and only the scripts I mentioned earlier are enabled!

Any assistance will be appreciated!

 

[srkbear]

My 2020 model says 3.0.0.4.384 as well as MAC, Serial and HW Ver and country of production.

The label covers some of the screws that hold the shell together. Those screws have tamper seals on them.

Here is an example in the Buy/Sell/Trade section, see the PICTURE showing the bottom:

SOLD - ASUS Routers! GT-AX11000, RT-AX58U

ASUS routers For Sale! ASUS RT-AX89X (dual 10G ports!) https://www.asus.com/networking-iot-servers/wifi-routers/asus-gaming-routers/rt-ax89x/ $295 shipped SOLD! ROG Rapture GT-AX11000 (2.5G port!) https://rog.asus.com/us/networking/rog-rapture-gt-ax11000-model/ $295 shipped SOLD! ASUS...

www.snbforums.com

Buddy I really appreciate your attempts to help—I think there may be a miscommunication somewhere. I’m referring to the brand new GT-6 ROG gaming router two pack that was just released to market a few weeks ago. It shipped with a firmware that was working for me, but when I upgraded it it stopped working. And when I went to the ASUS website it listed the upgrade firmware as the “initial” launch firmware, so I have no way of accessing the version it was shipped with anymore! Doesn’t make sense, but I’m stuck with returning it unfortunately :/

 

[brummygit]

People who had wifi issues on their RT-AX86U, can you see if this test image of the stock firmware resolves the issues? It contains a fix related to wifi:

RT-AX86U_3.0.0.4_388_22484-gdea54d4-test_pureubi.w

W File

1drv.ms

Make a backup of your settings before if you intend to switch back and forth between this stock firmware and my firmware, so you can easily revert back afterward.

I'm still running this test firmware on my RT-AX86U nodes and I think the WiFi performance I am getting from them is the best I have experienced. Everything is stable and my devices happily find the best radio between the RT-AX88U main router and the RT-AX86U nodes running this stock test firmware.

 

[octopus]

I'm still running this test firmware on my RT-AX86U nodes and I think the WiFi performance I am getting from them is the best I have experienced. Everything is stable and my devices happily find the best radio between the RT-AX88U main router and the RT-AX86U nodes running this stock test firmware.

I've been trying the test software in my Aimesh node for a few days and seems to be working fine.
Only problem is that after connecting to Aimesh node it cannot roam to master node again.
Need to turn off/on wifi for client to roam to master again.
Have the roaming assistance set to -62dbm

 

[NikL]

People who had wifi issues on their RT-AX86U, can you see if this test image of the stock firmware resolves the issues? It contains a fix related to wifi:

RT-AX86U_3.0.0.4_388_22484-gdea54d4-test_pureubi.w

W File

1drv.ms

Make a backup of your settings before if you intend to switch back and forth between this stock firmware and my firmware, so you can easily revert back afterward.

iRobot j7 doesn't work with this one.

 

[visortgw]

People who had wifi issues on their RT-AX86U, can you see if this test image of the stock firmware resolves the issues? It contains a fix related to wifi:

RT-AX86U_3.0.0.4_388_22484-gdea54d4-test_pureubi.w

W File

1drv.ms

Make a backup of your settings before if you intend to switch back and forth between this stock firmware and my firmware, so you can easily revert back afterward.

Asus has now released updated firmware: 3.0.0.4.388_22525.

Version 3.0.0.4.388.22525 (70 MB)
2023/02/07

1.Fixed CVE-2022-46871
2.Fixed Client DOM Stored XSS.
3.Improved AiMesh backhaul stability.
4.Fixed AiMesh topology UI bugs.
5.Fixed the reboot issue when assigning specific clients in VPN fusion.
6.Fixed the VPN fusion bug when importing the Surfshark WireGuard conf file.
7.Fixed network map bugs.

 

[octopus]

Asus has now released updated firmware: 3.0.0.4.388_22525.

Version 3.0.0.4.388.22525 (70 MB)
2023/02/07

1.Fixed CVE-2022-46871
2.Fixed Client DOM Stored XSS.
3.Improved AiMesh backhaul stability.
4.Fixed AiMesh topology UI bugs.
5.Fixed the reboot issue when assigning specific clients in VPN fusion.
6.Fixed the VPN fusion bug when importing the Surfshark WireGuard conf file.
7.Fixed network map bugs.

We know

Release - ASUS RT-AX86 Series(RT-AX86U/RT-AX86S) Firmware version 3.0.0.4.388.22525

ASUS RT-AX86 Series(RT-AX86U/RT-AX86S) Firmware version 3.0.0.4.388.22525 Version 3.0.0.4.388.22525 70 MB 2023/02/07 1.Fixed CVE-2022-46871 2.Fixed Client DOM Stored XSS. 3.Improved AiMesh backhaul stability. 4.Fixed AiMesh topology UI bugs. 5.Fixed the reboot issue when assigning specific...

www.snbforums.com

 

[AntonK]

Asus has now released updated firmware: 3.0.0.4.388_22525.

Version 3.0.0.4.388.22525 (70 MB)
2023/02/07

1.Fixed CVE-2022-46871
2.Fixed Client DOM Stored XSS.
3.Improved AiMesh backhaul stability.
4.Fixed AiMesh topology UI bugs.
5.Fixed the reboot issue when assigning specific clients in VPN fusion.
6.Fixed the VPN fusion bug when importing the Surfshark WireGuard conf file.
7.Fixed network map bugs.

Yes, but does it contain the fix associated with the 22484-test firmware?

 

[octopus]

Yes, but does it contain the fix associated with the 22484-test firmware?

Program is useless RM need source code.

 

[AntonK]

Program is useless RM need source code.

I was only questioning whether 3.0.0.4.388_22525 contained the fix @RMerlin released in the form of 22484-test firmware.

 

[octopus]

I was only questioning whether 3.0.0.4.388_22525 contained the fix @RMerlin released in the form of 22484-test firmware.

Merlin released 22484 2023/01/31 and 22525 released 2023/02/07 so probably not.

 

[visortgw]

I was only questioning whether 3.0.0.4.388_22525 contained the fix @RMerlin released in the form of 22484-test firmware.

I installed the update on my two (2) RT-AX86U AiMesh nodes earlier today, and I have seen the same wifi stability as with the 388_22484-test release that @RMerlin posted. I have not seen any of the IoT device issues on guest network 1 that I experienced with 388_22068, but I will continue to monitor.

 

[visortgw]

Merlin released 22484 2023/01/31 and 22525 released 2023/02/07 so probably not.

My expereience has been that if Asus releases a test firmware build, any subsequent firmware (based upon 5-digit build number — i.e., 22525 > 22484) that is released includes the fix that the test was build was supposed to address.

 

[RMerlin]

I was only questioning whether 3.0.0.4.388_22525 contained the fix @RMerlin released in the form of 22484-test firmware.

No idea. The firmware I uploaded was a test build, not part of the regular tree.

 

[karateca]

hello, me again, i haved this last week many lose connection with internet, first time i think was a problem with ISP, cuz change 600mb to 1gb of speed. But 2 days ago i change the firmware to the stock firmware and i dont have more disconnection. Today i go back to merlin firmware and even dont pass 2 hours and lose the connection again. Hope can help me with this plz.

Feb 9 18:31:13 pppd[1440]: Connection terminated.
Feb 9 18:31:13 pppd[1440]: Modem hangup
Feb 9 18:31:13 wlceventd: wlceventd_proc_event(491): eth7: Deauth_ind 40:2F:86:05:43:2C, status: 0, reason: Previous authentication no longer valid (2), rssi:0
Feb 9 18:31:13 wlceventd: wlceventd_proc_event(491): eth7: Deauth_ind 68:72:C3:81:A3:C8, status: 0, reason: Previous authentication no longer valid (2), rssi:0
Feb 9 18:31:13 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 8C:85:80:C9:FD6, status: 0, reason: Previous authentication no longer valid (2), rssi:0
Feb 9 18:31:13 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 8C:85:80:E7:F5:C4, status: 0, reason: Previous authentication no longer valid (2), rssi:0
Feb 9 18:31:13 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 54:48:E6:71:4B:B3, status: 0, reason: Previous authentication no longer valid (2), rssi:0
Feb 9 18:31:14 wlceventd: wlceventd_proc_event(508): eth7: Disassoc 40:2F:86:05:43:2C, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 9 18:31:15 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 8C:85:803:C9F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 9 18:31:16 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 8C:85:80:E7:F5:C4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 9 18:31:16 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 8C:85:80:C9:FD6, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 9 18:31:17 acsd: acs_candidate_score_busy(951): eth6: busy check failed for chanspec: 0x180a (8l)
Feb 9 18:31:17 acsd: acs_candidate_score_intf(1003): eth6: intf check failed for chanspec: 0x180a (8l)
Feb 9 18:31:17 acsd: acs_candidate_score_bgnoise(1320): eth6: bgnoise check failed for chanspec: 0x180a (8l)
Feb 9 18:31:17 acsd: acs_candidate_score_txop(1575): eth6: txop check failed for chanspec: 0x180a
Feb 9 18:31:17 acsd: acs_candidate_score_busy(951): eth6: busy check failed for chanspec: 0x180b (9l)
Feb 9 18:31:17 acsd: acs_candidate_score_intf(1003): eth6: intf check failed for chanspec: 0x180b (9l)
Feb 9 18:31:17 acsd: acs_candidate_score_bgnoise(1320): eth6: bgnoise check failed for chanspec: 0x180b (9l)
Feb 9 18:31:17 acsd: acs_candidate_score_txop(1575): eth6: txop check failed for chanspec: 0x180b
Feb 9 18:31:17 acsd: acs_set_chspec: 0x180a (8l) for reason APCS_CSTIMER
Feb 9 18:31:18 acsd: eth6: selected_chspec is 0x180a (8l)
Feb 9 18:31:18 acsd: eth6: Adjusted channel spec: 0x180a (8l)
Feb 9 18:31:18 acsd: eth6: selected channel spec: 0x180a (8l)
Feb 9 18:31:18 acsd: eth6: txop channel select: Performing CSA on chspec 0x180a
Feb 9 18:31:58 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:33:13 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:34:28 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:35:43 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:36:58 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:38:13 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:39:28 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:40:43 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:41:58 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:43:13 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:44:28 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:45:43 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:46:59 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:48:14 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:49:29 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:49:46 acsd: acs_candidate_score_busy(951): eth6: busy check failed for chanspec: 0x180a (8l)
Feb 9 18:49:46 acsd: acs_candidate_score_intf(1003): eth6: intf check failed for chanspec: 0x180a (8l)
Feb 9 18:49:46 acsd: acs_candidate_score_bgnoise(1320): eth6: bgnoise check failed for chanspec: 0x180a (8l)
Feb 9 18:49:46 acsd: acs_candidate_score_txop(1575): eth6: txop check failed for chanspec: 0x180a
Feb 9 18:49:46 acsd: acs_candidate_score_busy(951): eth6: busy check failed for chanspec: 0x180b (9l)
Feb 9 18:49:46 acsd: acs_candidate_score_intf(1003): eth6: intf check failed for chanspec: 0x180b (9l)
Feb 9 18:49:46 acsd: acs_candidate_score_bgnoise(1320): eth6: bgnoise check failed for chanspec: 0x180b (9l)
Feb 9 18:49:46 acsd: acs_candidate_score_txop(1575): eth6: txop check failed for chanspec: 0x180b
Feb 9 18:50:44 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:51:59 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:53:14 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:54:29 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:55:44 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:56:59 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:58:14 pppd[1440]: Timeout waiting for PADO packets
Feb 9 18:59:29 pppd[1440]: Timeout waiting for PADO packets
Feb 9 19:00:44 pppd[1440]: Timeout waiting for PADO packets
Feb 9 19:02:00 pppd[1440]: Timeout waiting for PADO packets
Feb 9 19:03:15 pppd[1440]: Timeout waiting for PADO packets
Feb 9 19:04:30 pppd[1440]: Timeout waiting for PADO packets
0:47 services: apply rules error(18891)
Feb 9 20:10:49 rc_service: httpds 1221:notify_rc restart_wan_if 0;restart_stubby
Feb 9 20:10:49 pppd[31707]: Unable to complete PPPoE Discovery
Feb 9 20:10:49 wsdd2[1849]: error: wsdd-mcast-v4: wsd_send_soap_msg: send
Feb 9 20:10:51 pppd[32125]: pppd 2.4.7 started by stolker, uid 0
Feb 9 20:11:02 services: apply rules error(18857)
Feb 9 20:11:02 zcip_client: configured 169.254.95.63
Feb 9 20:11:07 services: apply rules error(18891)
Feb 9 20:11:12 services: apply rules error(18891)
Feb 9 20:11:17 services: apply rules error(18891)
Feb 9 20:11:22 services: apply rules error(18891)
Feb 9 20:11:26 pppd[32125]: Timeout waiting for PADO packets
Feb 9 20:11:27 services: apply rules error(18891)
Feb 9 20:11:32 services: apply rules error(18891)
Feb 9 20:11:37 services: apply rules error(18891)
Feb 9 20:11:42 services: apply rules error(18891)
Feb 9 20:11:47 services: apply rules error(18891)
Feb 9 20:11:52 services: apply rules error(18891)
Feb 9 20:11:57 services: apply rules error(18891)
Feb 9 20:12:02 services: apply rules error(18891)
Feb 9 20:12:07 services: apply rules error(18891)
Feb 9 20:12:12 services: apply rules error(18891)
Feb 9 20:28:22 kernel: dhd_flow_rings_delete_for_peer: ifindex 0
Feb 9 20:28:22 kernel: dhd_prot_flow_ring_delete: Send Flow Delete Req RING ID 194 for peer 58:bf:25:2d:f2:38 prio 5 ifindex 0
Feb 9 20:28:22 kernel: dhd_prot_flow_ring_delete_response_process: Flow Delete Response status = 0
Feb 9 20:28:22 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 58:BF:25:2D:F2:38, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Feb 9 20:28:22 kernel: dhd_flow_rings_delete_for_peer: ifindex 0
Feb 9 20:28:22 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 58:BF:25:2D:F2:38, status: 0, reason: Previous authentication no longer valid (2), rssi:0
Feb 9 20:28:22 kernel: CONSOLE: 108279.167 iov:SCB_DEAUTH
Feb 9 20:28:22 kernel: CONSOLE: 108279.167 wl0.0: wlc_ampdu_flush_scb_tid flushing 0 packets for 58:bf:25:2d:f2:38 AID 22 tid 5
Feb 9 20:28:22 kernel: CONSOLE: 108279.169 iov:SCB_DEAUTH
Feb 9 20:28:22 kernel: CONSOLE: 108279.169 iov:SCB_DEAUTH
Feb 9 20:28:22 kernel: CONSOLE: 108279.191 iov:SCB_DEAUTH
Feb 9 20:28:22 kernel: CONSOLE: 108279.191 iov:SCB_DEAUTH
Feb 9 20:28:23 wlceventd: wlceventd_proc_event(527): eth6: Auth 58:BF:25:2D:F2:38, status: Successful (0), rssi:0
Feb 9 20:28:23 wlceventd: wlceventd_proc_event(556): eth6: Assoc 58:BF:25:2D:F2:38, status: Successful (0), rssi:0
Feb 9 20:28:23 kernel: CONSOLE: 108279.831 wlc_ap_authresp: status 0
Feb 9 20:28:23 kernel: CONSOLE: 108279.834 wlc_ap_process_assocreq_done status 0
Feb 9 20:28:23 kernel: CONSOLE: 108279.836 iov:SCB_DEAUTH
Feb 9 20:28:23 kernel: CONSOLE: 108279.837 txrep:802.1x
Feb 9 20:28:23 kernel: CONSOLE: 108279.839 wl0.0: wlc_send_bar: for 58:bf:25:2d:f2:38 seq 0x1 tid 5
Feb 9 20:28:24 services: apply rules error(18891)
Feb 9 20:28:24 kernel: CONSOLE: 108280.833 txrep:802.1x
Feb 9 20:28:25 kernel: CONSOLE: 108281.828 txrep:802.1x

 

[128bit]

hello, me again, i haved this last week many lose connection with internet, first time i think was a problem with ISP, cuz change 600mb to 1gb of speed. But 2 days ago i change the firmware to the stock firmware and i dont have more disconnection. Today i go back to merlin firmware and even dont pass 2 hours and lose the connection again. Hope can help me with this plz.

i've been doing merlinware for years now. 388 by far was unusable - a first for me. stockware also sucked. asked for help and was totally ignored - twice even! yet another first. i've not jumped on the latest 2/7/23 release.

while i do applaud the fine work eric does, sw is tough. it seems like he's the single developer for a worldwide product. that in itself is insane. i've done global software as a profession and it's intense. how he manages to do all that he does astonishes me.

i will likely pass on the next couple releases until things settle. i reverted to 386.72 which was always stable and runs like a thoroughbred. i don't run mesh but use a vpn and some static ip's at home with about 30 clients. it's solid as a rock.

 

[domic]

Is it safe to downgrade to 386.7_2 from 388.1 for now and keep existing configs?

 

[128bit]

Is it safe to downgrade to 386.7_2 from 388.1 for now and keep existing configs?

i did it BUT since i tried 388 at least 3 times then the previous stockware (prior to 2/7) i did hard resets. i was being extra cautious due to all the problems. you may not have to but if you use vpn director, there may be a change, can't recall as it's been awhile. still, reverting was quite worthwhile for me as 386.72 remains solid.

 

[TimmyL]

Can't connect to NORDvpn, after fallback from ASUS the latest firmware version 3.0.0.4.388.22238, back to Merlin 388.2 Alpha, but get the system Log:
ovpn-client1[8907]: --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Feb 10 13:19:11 ovpn-client1[8907]: Options error: You must define CA file (--ca) or CA path (--capath)
Feb 10 13:19:11 ovpn-client1[8907]: Use --help for more information.
Feb 10 13:19:11 openvpn: Starting OpenVPN client 1 failed!
Since there is no such setting in Merlin firmware , such as Cipher Negotation and Legacy/fallback cipher,
will there be any one here can help me to solve this problem.
or can I fill in something in the attached fields ?

Thanks
Asus GT-AXE11000 @388.2 Alpha