What's new

Release Asuswrt-Merlin 386.4 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Device: RT-AX88U
Upgrade: Dirty from 386.3_2
Uptime from flash: ~30 hours
Stuff: Around 13 WiFi devices most of them using 2,4 GHz (2 Echo dot 3rdG - 2 Google Home - 1 Foscam camera - 1 TP-Link switch - 1 Xiaomi TV stick - 1 Fire TV stick - Some tablets and mobile phones), a couple of mobile phones on 5 GHz and some PCs via Ethernet.
Config: Very simple. No VPN server or clients, no DHCP server (Pi-hole), no IPv6, no DDNS, just a USB pen saving traffic analyzer data.
Problems: Not at all.

Thanks for your work, @RMerlin
 
Last edited:
I am one of the people seeing the "potentially unexpected fatal signal 11."
If I turn off pixel-tls, it goes away, but if I enable Pixel-tls and deactivate all the trend micro stuff in the AiProtection tabs, I *still* get this error. Is there some other trend micro stuff I need to turn off or is there something baked into the firmware that just won't allow us to use pixel-tls anymore? (sorry for beating this dead horse)
Did you hit unaccept to all of the disclaimers?
 
I have a script that checks (every hour) whether devices can still be reached from the router (via ping).

Lately I get multiple push notifications per day to inform me that a device (always the same, ironically the one closest to the router), connected on the 2.4 GHz band, cannot be reached. This device still shows a connected status on its screen, but it really cannot be ping’d.

I think this started with 386.4
From personal experience, I learned that some Android based devices will not respond to ping requests if they are in power savings mode. I had to add a check for power save status to know if a ping test would be valid.
 
So maybe you need it set to BOTH, but that’s dumb.

This is what I see here:

HTTP only - crash
HTTPS only - OK
BOTH - OK

From Version History:
- Security and privacy reinforcement, adjust https as default authentication protocol

Instead of force closing on http though, it could show a notification that https is not enabled. Not too many users read Version History for every app updated. Apps update automatically on most phones, sometimes 10 at a time. The app still needs some improvement. I like the theme options.
 
After a long wait, the new version of Asuswrt-Merlin is now available. 386.4 merges with GPL 386_45958 (plus a number of security fixes backported from newer code), updates various components, and also adds support for the RT-AX86S (uses the same firmware as the RT-AX86U).

The highlights of this release;
  • Merges with GPL 386_45958.
  • Adds support for the RT-AX86S (uses the same firmware as the RT-AX86U).
  • HND firmware now include both the kernel module and userspace tool for Wireguard. There is no built-in support for Wireguard at this time, these are only included for end-user or third party usage. Asus is still working on their own implementation, which isn't available yet.
  • OpenVPN server now supports IPv6, both for incoming connections, and for routing access to the LAN clients over IPv6. Note however that redirecting IPv6 Internet traffic through your server is not supported.
  • Component updates: curl 7.79.1, vsftpd to 3.0.5, openssl to 1.1.1m, wget to 1.21.1, nettle to 3.7.3, dnsmasq 2.86, openvpn 2.5.5, tor 0.4.5.11, miniupnpd 2.2.3-git 20211017, inadyn 2.9.1 and amtm 3.2.2.
  • jitterentropy-rngd was replaced by haveged. Haveged is more resource-intensive, but it works properly under older 2.6.x kernels.
  • dnsmasq was reverted back to using nettle for its DNSSEC crypto handling (since openssl support never got mainlined and was increasingly problematic to support)
  • miniupnpd now uses the real public IP address instead of any potentially (double-)NATed address for the WAN.
  • Reworked DHCP hostname support to use Asus's own implementation.
  • A couple of various bugfixes

Please review the Changelog for complete details.

Notes:
  • 386.4 uses the new DHCP hostname implementation from Asus (your entries will automatically be converted to the new format on first boot). This means however that reverting to a previous firmware version will lose all of your defined static lease hostnames, so backup your configuration before upgrading if you expect you might need to downgrade afterward.
Please keep posts in this thread on this specific release. This thread will be locked after a few weeks once the release feedback has died down.

Downloads are here.
Changelog is here.
Thank you very much for the new firmware RMerlin.
Running very smooth on my new RT-AX86U.

I have tried to find how the including of the Wireguard kernel and userspace tool, changes the implementation of installing Wireguard or add support for the Wiregaurd protocol on the router for the built-in VPN Client?
Can anyone point out what options there are and how to to that the best with this new firmware?

The info that I have found on implementing Wireguard prior to this new firmware change is the following for previous firmware:
 
From personal experience, I learned that some Android based devices will not respond to ping requests if they are in power savings mode. I had to add a check for power save status to know if a ping test would be valid.
Interesting!

However this device gets its power (220V) from an outlet and does not have an Android stack.

I doubt it has a power save mode, but I’m not sure about that.
 
NTFS is a disk filesystem, that has nothing to do with wifi...
well, more broadly, since the ssd is directly attached and managed by the router with syslog error entries. i tend to mash it together as a networking issue. a health scan via the internal ui made it all better. the scan found no errors so wondering if the dismount/mount may have been all that was necessary.

your comments re your personal experiences helped me take the leap. so all's well here,
. . . obliged
 
In the past, Asus's tri band routers limited DFS channels to only the first radio, as they split UNII-2a and UNI-2c channels between the first and second radio. If they allow the full 5 GHz spectrum on both bands now then this would be something new.
ASUS is still splitting the channels between the first and second radios, UNII-2a for radio one and, UNII 2c and UNII 3 for radio two. But unless I'm mistaken, DFS is applicable to UNII 2c channels?
 
This is what I see here:

HTTP only - crash
HTTPS only - OK
BOTH - OK

From Version History:
- Security and privacy reinforcement, adjust https as default authentication protocol

Instead of force closing on http though, it could show a notification that https is not enabled. Not too many users read Version History for every app updated. Apps update automatically on most phones, sometimes 10 at a time. The app still needs some improvement. I like the theme options.
Switch to BOTH and now the app lets me log in.
Switch back to HTTPS only and it crashes again when the app is connecting.

Odd it works for you on HTTPS only but not me.

For now I’ll just enable BOTH and keep an eye on the change logs for the app.
 
This is what I see here:

HTTP only - crash
HTTPS only - OK
BOTH - OK

From Version History:
- Security and privacy reinforcement, adjust https as default authentication protocol

Instead of force closing on http though, it could show a notification that https is not enabled. Not too many users read Version History for every app updated. Apps update automatically on most phones, sometimes 10 at a time. The app still needs some improvement. I like the theme options.
The app works for me with HTTP only. Even the most recent update from iOS.
 
The app works for me with HTTP only. Even the most recent update from iOS.
The other variables might be related to ports used and if you have a self signed or Let’s Encrypt cert installed.
 
It has to be enabled for who wants to use the app, no choice. Even the settings can't be changed from the app, Apply doesn't work. I had to enable both from the GUI. I didn't notice any browser issues, Chrome with certificate installed. AC68U on Asuswrt.
The app is the last of my concerns tho, since it will never be 100% compatible with my firmware.
ASUS is still splitting the channels between the first and second radios, UNII-2a for radio one and, UNII 2c and UNII 3 for radio two. But unless I'm mistaken, DFS is applicable to UNII 2c channels?
Correct. I checked, and they have the lower DFS Channels in UNII-2a, and the higher DFS channels in UNII-2c. I thought that at the time they only allowed channels 150-ish and up on the second radio.
 
Hi,
Has the port forwarding been modified on the last 386.4 update ? I use a rule that doesn't work anymore since the update (no access to my nas from outside) :(
I use an RT-AX88U.
 
Hi,
has the port forwarding been modified on the last 386.4 update? I use a rule that doesn't work anymore since the update (no access to my nas from outside) :(
For security reasons alone, use a VPN instead of port forwarding.
 
For security reasons alone, use a VPN instead of port forwarding.
thank you for your answer. I agree, but how come the port forwarding doesn't work anymore ? My rule is the same and I don't have to change anything. It looks like the port stays closed when it's actually open...
 
thank you for your answer. I agree, but how come the port forwarding doesn't work anymore ? My rule is the same and I don't have to change anything.
All working the same for me. You'll have to provide details of what you're forwarding and what diagnostics you've done so that we can try to recreate it.
 
All working the same for me. You'll have to provide details of what you're forwarding and what diagnostics you've done so that we can try to recreate it.
From the outside and it doesn't work anymore...
 
Last edited:
Hmm, I have to wonder why some of these questions are being asked in this thread, and NOT as individual posts, as normal. Seems to me *this* thread should be narrowly focused on issues directly related to installation of the firmware. I could understand it if this was still the beta thread, but NOT once it's released. Just makes it more difficult to provide support, track problems, and make these issues known to others.
 
this is my rule :
View attachment 38475
I try to access my host name "https://xxxx.synology.me:xxxx" from the outside and it doesn't work anymore.
Just checked it again here and it's working fine. Forwarding external port 5555 to internal port 443.

Check the rule is present under System Log - Port Forwarding.

Also check that xxxx.synology.me still resolves to your WAN IP.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top