Release Asuswrt-Merlin 3004.388.6 is now available

[RMerlin]

Correction: I just checked and except for compiled-in timestamps &c.. all files check out the same between 6b1 and 6 release, except that there are changes in the release version for:
/usr/networkmap/networkmap.oui.js
/www/help.js
/www/QoS_Stats.asp

Github is your friend there.

merlin@ubuntu-dev:~/amng$ git log --oneline 3004.388.6-beta1..3004.388.6
24569f6134 (HEAD -> master, tag: 3004.388.6, origin/master) Bumped revision to 3004.388.6 final
f7d0b8c61e Updated documentation
e926445fd6 httpd: properly parse UPNP leases without a description
5fb4af4340 networkmap: webui: updated OUI database
45156a0045 webui: fix report of 2 GHz radio state on GT-AXE16000
597fb39c97 httpd: skip tc filters not using the same mask as regular Adaptive QoS entries
9cdd3f43fd webui: take into account all four possibilities when tracking eLearning category

As you can see, there were also changes to httpd.

 

[Rhyalus]

Hello All! Happy RT-AX88U owner here, on 386.4 since it was released.

Rock solid...no issues at all.

The only reason I want to consider updating is only to mitigate potential security risks. Can anyone comment on the "risk" of moving to RT-AX88U_3004_388.6_0 vs the risk of not?

Thanks,
R

 

[glens]

Github is your friend there.

Thank you for that command. I figured there must be something that easy to do, but have never messed much with git.

 

[ax8]

Just sharing this in-case anyone on the same hardware experiences the same thing.
I've experienced problems on my AX88U after upgrading from .5 to .6.
In my case the ethernet ports seemed to stop working, including the WAN interface.
In case anyone else finds themselves in this situation the resolution for me was connecting to the router via WiFi and 'updating' it back to .5 (I still had the file, but you can do it over 4\5g if you don't. ).
After the issue occurred and I rolled back I tried upgrading to .6 again and had the exact same issue so I'm guessing something in my configuration in particular in conflicting with the upgrade process. I haven't had time to trouble shoot further or do a factory reset, fresh install and reconfigure so that may well work just fine.

Note both times when I rolled back to v .5 from .6 it took two goes, i.e. the first time I uploaded the firmware and rebooted it was still v .6, then the second it rebooted it was back to v.5 perfectly fine and stable.

 

[swejuggalo]

I guess I've forgotten which hardware you guys are discussing, but I've been running the 6b1 (which I believe checked out the same as the release) for 28 days and change on a GT-AX6000. What's your issue?

If you refer to my hardware, RT-AX88U (non Pro). I can get random disconnects of everything. By the looks of the logs, everything seems to start over (reboot). However, not been able to capture any actual error before it happens. And the error can come everything from a few hours to many days apart.

The problem I had before in 388.5 was found, but I wiped then too. Even if the issue got resolved, just to see if I could replicate the issue when starting over from scratch. Also wiped in 388.6 beta.
Anyway, this behaviour that started with 388.6 is new. Whatever happens, it would be fun to find a clue on what happens.

Now I'm back on a wiped router again, with untouched WiFi settings, Diversion, Skynet, DDNS, SSH, DoT, VPN and such configured. Showing logs at warning level and hope to grab something if it happens again. Maybe next week, or even later, who knows. Maybe then I see if it helped.

 

[swejuggalo]

BTW, VPN still seems to require manual renew of certificates to work. I assume the normal behaviour should be to valid right from the first time you turn the VPN server on.

 

[swejuggalo]

I use the app VPN Client Pro for OpenVPN.
The exported profile uses "data-ciphers" when imported, and that triggers a warning.

"2024-02-04 10:28:27 Note: --cipher is not set. OpenVPN versions before 2.5 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."

Change to "cipher" and the warning stops. Is this kept to support older OpenVPN (2.4.0)?
Note: profile file says "ncp-ciphers" before imported.

Does this mean something should be updated in the firmware or simply be ignored?

 

[Gravityz]

If you refer to my hardware, RT-AX88U (non Pro). I can get random disconnects of everything. By the looks of the logs, everything seems to start over (reboot). However, not been able to capture any actual error before it happens. And the error can come everything from a few hours to many days apart.

The problem I had before in 388.5 was found, but I wiped then too. Even if the issue got resolved, just to see if I could replicate the issue when starting over from scratch. Also wiped in 388.6 beta.
Anyway, this behaviour that started with 388.6 is new. Whatever happens, it would be fun to find a clue on what happens.

Now I'm back on a wiped router again, with untouched WiFi settings, Diversion, Skynet, DDNS, SSH, DoT, VPN and such configured. Showing logs at warning level and hope to grab something if it happens again. Maybe next week, or even later, who knows. Maybe then I see if it helped.

is this everything or only wifi
if only wifi check the protected management frames and set it to DISABLE

 

[joegreat]

I had a similar problem during the beta, and again this morning when I tried to upgrade from 3004.388.5 to .6 - nothing seemed to be working, and (the clue was) nothing seemed to be able to resolve DNS addresses. Once I realized that hint, I went to the system log and found that DNSMASQ startup was failing with a bad line in the /etc/dnsmasq.conf file.

For me, the bad line was dns-forward-max=500 which I had added via /jffs/configs/dnsmasq.conf.add. It turns out that this latest release has added the dns-forward-max=1500 directive - dnsmasq won't accept duplicate entries (you have to edit these with /jffs/scripts/dnsmasq.postconf if you want to change an existing directive). Once I commented out my (newly duplicated) entry, I was able to upgrade to 3004.388.6 without problem.

So...check your system logs for a failed dnsmasq startup (or any other errors that aren't there when you boot up the 3004.388.5 release).

Yep, same here:

After update to 3004.388.6 (coming from .5) I found dnsmasq not working anymore. See syslog entries:

/tmp/syslog.log
May  5 07:05:04 dnsmasq[1193]: illegal repeated keyword at line 59 of /etc/dnsmasq.conf
May  5 07:05:04 dnsmasq[1193]: FAILED to start up

By looking into the /etc/dnsmasq.conf, I found the causing entry (leftover from some DNS/Stubby debugging):

/jffs/config/dnsmasq.conf.add
dns-forward-max=512

I didn't find anything related to dnsmasq in the changelog for 3004.388.6, but it looks like the default dnsmasq.conf changed by setting this entry now as default to value 1500.
Removing my duplicate .conf.add entry solved the issue for me.

 

[swejuggalo]

is this everything or only wifi
if only wifi check the protected management frames and set it to DISABLE

It's everything. 2.4 GHz with WPA2/WPA3 and 5 GHz with WPA3. Rare with a specific client dropping by itself. But everything, including wired, at the same time is more critical. Even if I pretty much never notice it besides seeing the uptime being reset.

 

[ColinTaylor]

Now I'm back on a wiped router again, with untouched WiFi settings, Diversion, Skynet, DDNS, SSH, DoT, VPN and such configured.

Why have you reenabled Skynet when you said it was spamming your syslog?

Showing logs at warning level and hope to grab something if it happens again.

You should set "Log only messages more urgent than" to "all" otherwise you'll miss important information making the whole exercise pointless.

 

[swejuggalo]

Why have you reenabled Skynet when you said it was spamming your syslog?


You should set "Log only messages more urgent than" to "all" otherwise you'll miss important information making the whole exercise pointless.

Well... if it blocks a connection and reports it, it's not broken right?

If solved now anyway, then I would be done. If not I could disable Skynet again. Do a test run with showing all logs. Backstepping rather than running with a config for approx two weeks that I don't plan to use anyway was my thought... but OK. I'll run without Skynet for a week or 2.

So critical errors that results in a drop of everything/reboot does not produce enough info in a warning+ to be useful?

What if the problem turns out to be happening only when using Skynet? Apparently running a Syslog server does not add any value to find this problem. And I would be back to square 1 without being able to produce a log with relevant info.

 

[ColinTaylor]

Well... if it blocks a connection and reports it, it's not broken right?

This was never about whether Skynet was broken or not. It was because you said Skynet was creating so much log spam that your syslog only went back 10 minutes, which meant you lost any useful information.

 

[L&LD]

Hello All! Happy RT-AX88U owner here, on 386.4 since it was released.

Rock solid...no issues at all.

The only reason I want to consider updating is only to mitigate potential security risks. Can anyone comment on the "risk" of moving to RT-AX88U_3004_388.6_0 vs the risk of not?

Thanks,
R

Always, YMMV.

As it is only ~5 months old, you may want to hold off for 388.6.xx or 388.7... depending on how soon that may (or may not) be released.


You can also check the following link and search what changes/fixes have been brought with the last two releases vs the one you're running now.

Reading the changelog isn't enough though. You also need to do further searches to understand why certain components were upgraded/updated too (individually). The changelog won't (usually) offer that insight.

Changelog (388.x) | Asuswrt-Merlin

asuswrt-merlin.net

What I would do in your place (see below)?

Is it a good idea to keep up with Firmware updates?

I have had issues in the past when updating firmware and Internet speed, But it may have just been a fluke, Should I keep up with the updates? If so On all routers or the nodes as well? What about ones acting as access points? Thanks

www.snbforums.com

After doing what is outlined in the above link, download the latest firmware and install it.

If there are any issues, be prepared to do a full reset on the router. Fully format any USB drives (that were being used for amtm and/or any scripts), to NTFS format on a PC before inserting it back into the freshly formatted router. Now, perform a Minimal and Manual configuration to secure the router and connect to your ISP. Do NOT import any old backup config file. This will negate the full reset you just performed.

Slowly (i.e. one at a time) add (only) your needed customizations and enable the features and options you require. Keep excellent notes. Be sure you are rebooting the router after every change you make to ensure the changes 'stick' and that the router/network is still acting as expected.

With any luck, you may find you need to do nothing further.

If issues persist that a forum search or asking for help (with specifics) doesn't give results, you always have the option to use the files you made from the first link above to quickly put your router/network back into the same place you're in today, in 10 minutes or less.

Hope this helps.

 

[swejuggalo]

This was never about whether Skynet was broken or not. It was because you said Skynet was creating so much log spam that your syslog only went back 10 minutes, which meant you lost any useful information.

True, but at this stage I don't know if the problem even exist anymore.
I could be waiting on something that does not happen.

If it ends up happening only when Skynet is active, like any possible stressing the system for example, I would still need to capture something of value.

BTW, found out that Skynet without logging the blocked connections does not produce anything in syslog.

 

[RMerlin]

Thank you for that command. I figured there must be something that easy to do, but have never messed much with git.

I always tag beta and final releases, so it's easy to get the list of commits between two specific tags over the command line (I doubt the same can be done with the Github website however).

Does this mean something should be updated in the firmware or simply be ignored?

Just ignore it - it is a warning, not an error.

The reason why I still include this legacy setting is for compatibility with older clients.

 

[dave14305]

(I doubt the same can be done with the Github website however).

It’s not intuitive to get to, but the equivalent URL is :

Comparing 3004.388.6-beta1...3004.388.6 · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - Comparing 3004.388.6-beta1...3004.388.6 · RMerl/asuswrt-merlin.ng

github.com

View all tags, click 3004.388.6 tag, click the compare button, select 3004.388.6-beta1.

 

[EdoAsus]

Just sharing this in-case anyone on the same hardware experiences the same thing.
I've experienced problems on my AX88U after upgrading from .5 to .6.
In my case the ethernet ports seemed to stop working, including the WAN interface.
In case anyone else finds themselves in this situation the resolution for me was connecting to the router via WiFi and 'updating' it back to .5 (I still had the file, but you can do it over 4\5g if you don't. ).
After the issue occurred and I rolled back I tried upgrading to .6 again and had the exact same issue so I'm guessing something in my configuration in particular in conflicting with the upgrade process. I haven't had time to trouble shoot further or do a factory reset, fresh install and reconfigure so that may well work just fine.

Note both times when I rolled back to v .5 from .6 it took two goes, i.e. the first time I uploaded the firmware and rebooted it was still v .6, then the second it rebooted it was back to v.5 perfectly fine and stable.

I had a similar problem upgrading to 388.5 on my AX88U, the WAN port was not working properly, after I upgraded to 388.6 I decided to do a factory reset and configured all manually from scratch, issue solved. Sometimes factory reset is mandatory, so try that and do all settings manually again, see if it solves the problem.

 

[DiscoSi]

Has anyone had issues getting more that 20MHz on channels above 100 on 388.6? My router is the AX11000Pro so Tri-Band, not sure if that's anything to do with it?

It's completely repeatable as I've gone back to stock and also Merlin 388.5 with full Factory reset and reconfigure in between. I get at least 80MHz on the second 5GHz channel which uses channels 100+ on both of those. As soon as I go to 388.6 it's limited to 20Mhz only. I guess it's the latest Broadcom driver in 388.6 being much more sensitive to Radar interference? 388.5 & 388.6 wireless log below for comparison.

388.6
SSID: "xxxxxxxxx"
noise: -99 dBm Channel: 104
BSSID: xx:xx:xx:xx:xx:xx Capability: ESS RRM
Supported Rates: [ 6(b) 9 12(b) 18 24(b) 36 48 54 ]
HE Capable:
Chanspec: 5GHz channel 104 20MHz (0xd068)
Primary channel: 104
HT Capabilities: 40Mhz SGI20 SGI40
Supported HT MCS : 0-31
Supported VHT MCS:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11
NSS4 Tx: 0-11 Rx: 0-11
Supported HE MCS:
80 Mhz:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11
NSS4 Tx: 0-11 Rx: 0-11
160 Mhz:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11
NSS4 Tx: 0-11 Rx: 0-11
QBSS Channel Utilization: 0x8 (3 %)

Interference Level: Acceptable
Mode : AP Only

DFS status: state In-Service Monitoring(ISM) time elapsed 96300ms radar channel cleared by DFS channel 104 (0xD068)

Channel Information
----------------------------------------
Channel 100 A Band, RADAR Sensitive, Passive
Channel 104 A Band, RADAR Sensitive
Channel 108 A Band, RADAR Sensitive, Passive
Channel 112 A Band, RADAR Sensitive, Passive
Channel 116 A Band, RADAR Sensitive, Passive
Channel 120 A Band, RADAR Sensitive, Passive
Channel 124 A Band, RADAR Sensitive, Passive
Channel 128 A Band, RADAR Sensitive, Passive
Channel 132 A Band, RADAR Sensitive, Passive
Channel 136 A Band, RADAR Sensitive, Passive
Channel 140 A Band, RADAR Sensitive, Passive

388.5
SSID: "xxxxxxxxxx"
noise: -92 dBm Channel: 108/80
BSSID: xx:xx:xx:xx:xx:xx Capability: ESS RRM
Supported Rates: [ 6(b) 9 12(b) 18 24(b) 36 48 54 ]
HE Capable:
Chanspec: 5GHz channel 106 80MHz (0xe26a)
Primary channel: 108
HT Capabilities: 40Mhz SGI20 SGI40
Supported HT MCS : 0-31
Supported VHT MCS:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11
NSS4 Tx: 0-11 Rx: 0-11
Supported HE MCS:
80 Mhz:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11
NSS4 Tx: 0-11 Rx: 0-11
160 Mhz:
NSS1 Tx: 0-11 Rx: 0-11
NSS2 Tx: 0-11 Rx: 0-11
NSS3 Tx: 0-11 Rx: 0-11
NSS4 Tx: 0-11 Rx: 0-11
QBSS Channel Utilization: 0x9 (3 %)

Interference Level: Acceptable
Mode : AP Only

DFS status: state In-Service Monitoring(ISM) time elapsed 19650ms radar channel cleared by DFS channel 108/80 (0xE26A)

Channel Information
----------------------------------------
Channel 100 A Band, RADAR Sensitive
Channel 104 A Band, RADAR Sensitive
Channel 108 A Band, RADAR Sensitive
Channel 112 A Band, RADAR Sensitive
Channel 116 A Band, RADAR Sensitive, Passive
Channel 120 A Band, RADAR Sensitive, Passive
Channel 124 A Band, RADAR Sensitive, Passive
Channel 128 A Band, RADAR Sensitive, Passive
Channel 132 A Band, RADAR Sensitive, Passive
Channel 136 A Band, RADAR Sensitive, Passive
Channel 140 A Band, RADAR Sensitive, Passive

------------------------------------------------------------------------------------

The 5GHz channel 1 is unaffected and hits 160GHz just fine. I've tried messing with various wifi settings but none make any difference. I'm hoping this is something that can be fixed by Merlin but I totally get that it's probably in the closed source driver/s.

Anyone else with a 11000Pro or other triband router able to confirm the same? I'm hoping this isn't the way it's going to go from now on as I'll have to rethink my setup, I've always been able to get 80Mhz in channels above 100 on this and previous Asus routers without issue so I don't think local radar interference has changed overnight. My AX56U manages just fine as well.

Thanks all

 

[nlurker]

Since I changed Auto Logout from zero to 999 three days ago, it has not logged me out at all. It has been continuously updating for way more than 999 minutes.

Please tell ASUS that the Auto Logout = 0 setting is broken in 388.6. It appears that 999 now functions like 0 did previously, but the setting page still says (Disable : 0), which does not work.

I am pleased to report that after 10 days, I still have not been logged out a single time. Even after restarting my browser and rebooting my computer, I am staying logged in. This is even better than I previously experienced with the zero setting, which would occasionally log me out.