What's new

Beta Asuswrt-Merlin 386.4 beta 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.
Update smooth and running sweet, like sweet cream on peaches. Thanks Rmerlin!
 
Dirty upgrade from 386.4_alpha3-g092f25da96 to 386.4_beta1 on a RT-AC86U. So far so good !!!
 
Asuswrt-Merlin 386.4 is now available for all supported models. This release merges with GPL 386_45958, and adds support for the RT-AX86S.

There has been a long gap between these last releases due to licensing issues Asus had to resolve with the generated GPL archives. There are still a few remaining issues that are currently forcing me to delay support for the RT-AC68U_V4 and GT-AXE11000, these will need to be revisited once their respective GPL archives are fixed by Asus and Broadcom.

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 firmwares 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.1l, wget to 1.21.1, nettle to 3.7.3, dnsmasq 2.86, openvpn 2.5.4, tor 0.4.5.11, miniupnpd 2.2.3-git 20211017 and inadyn 2.9.1
  • 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.

Things that needs particular testing and feedback:
  • OpenVPN server IPv6 support. I was only able to do limited testing using an HE tunnel.

Please keep posts in this thread on this specific release.

Downloads are here.
Changelog is here.
dnsmasq was reverted back to using nettle for its DNSSEC crypto handling (since openssl support never got mainlined and was increasingly problematic to support)

Not knocking your choice to switch to Nettle from Openssl, but what were some of the problems you were facing with keeping Openssl for crypto? Was it a matter of keeping up with the libraries, or was it giving difficulties at compile time? I know themiron use to help maintain it. (Nothing wrong with using Nettle.)

There are still a few remaining issues that are currently forcing me to delay support for the RT-AC68U_V4 and GT-AXE11000, these will need to be revisited once their respective GPL archives are fixed by Asus and Broadcom.

Also, What issues are you (or Asus) currently facing with the RT-AC68U_V4 and GT-AXE11000.
 
I have a problem with DDNS (Asus) status that is inactive for some reason.Dynamic WAN ipv4 won't get updated if it's changed

Related logs:
Dec 17 01:57:57 rc_service: httpd 1404:notify_rc restart_ddns_le
Dec 17 01:57:57 start_ddns: eth0 has not yet obtained an ipv6 address
Dec 17 02:00:00 rc_service: service 4463:notify_rc restart_letsencrypt
Dec 17 02:00:00 Let's_Encrypt: Err, DDNS update failed.
It's Asus's recent IPv6 implementation in ddns which seems to still be broken. I needed that tested since I had fixed a separate issue, and was wondering if it might also fix this second one (can't test myself, no IPv6 support with my ISP).

I will most likely disable IPv6 support in the next release, and wait for Asus to fix it on their end.
 
Thanks for resolving the /opt issues in alpha3. However, I am still experiencing the condition where the Network Map briefly shows a working internet connection, but then switches to 'Disconnected', and the wan link LED always shows red, instead of the previous white (up through 386_4.alpha2). I did a dirty upgrade from 386_4.alpha3 to 386_4.beta1 on an RT-AX3000 (RT-AX58U firmware). I use DNS-over-TLS, and am in a situation where my router is behind an ISP's router on an IPv4-only network (i.e. the ISP does not support IPv6). So, my WAN address is in the subnet 192.168.1.0/24. I do not have WAN monitoring enabled (neither DNS or Ping).
Make sure you don't interfere with the router trying to ping the Microsoft server used to determine if the connection is up.
Not knocking your choice to switch to Nettle from Openssl, but what were some of the problems you were facing with keeping Openssl for crypto? Was it a matter of keeping up with the libraries, or was it giving difficulties at compile time? I know themiron use to help maintain it. (Nothing wrong with using Nettle.)
dnsmasq only supports nettle. @themiron implemented OpenSSL support to it in a dnsmasq fork, and we were initially hoping that Simon might eventually adopt it in the official dnsmasq release. It didn't happen, and since the OpenSSL implementation is quite complex, it meant every time a new dnsmasq release was issued, I had to wait for themiron to update his fork and adapt his patches to the new code. Since he no longer has the time to regularly keep it up-to-date due to his new job, I didn't want to get locked out of critical dnsmasq updates, and decided to simply switch back to the stock dnsmasq code. Otherwise 386.4 would still be stuck with 2.84.
 
Also, What issues are you (or Asus) currently facing with the RT-AC68U_V4 and GT-AXE11000.
Wifi is broken. Radios initialize, but the power output is at pretty much 0 dbm, meaning if lucky, I might get a -92 dbM signal when my laptop is one feet away from the router.

The issue only occurs with the GPL generated components, which is puzzling Asus. The issue got escalated to BCM, and after a few weeks we're still waiting for a resolution, so I decided to stop waiting, and simply drop these two.
 
@RMerlin

Thanks for the new Beta. Just like to report a Small OpenVPN Connection Status issue.

VPN -> VPN Status Tab -> OpenVPN Server 1
All is well and good, showing both Clients and Routes correctly.
Screenshot 2021-12-17 at 12.18.23.png


However,
VPN - VPN Server Tab - > VPN Server - OpenVPN -> Connection Status
Is shown as Disconnected for the same Client

Screenshot 2021-12-17 at 12.25.14.png


PS:
  • I have IPV6 (Native) setup and running correctly based on https://ipv6-test.com on my MacBookPro.
  • However, On my MacBookPro with Tunnelblick 3.8.8beta02 (build 5780), the OpenVPN connection over my iPhone Cellular Hotspot, https://ipv6-test.com ... shows there is no IPv6, only IPv4
  • What else can I test on OpenVPN and IPv6? if you can give me specific instructions. I can do the tests. Thanks.
 
It's Asus's recent IPv6 implementation in ddns which seems to still be broken. I needed that tested since I had fixed a separate issue, and was wondering if it might also fix this second one (can't test myself, no IPv6 support with my ISP).

I will most likely disable IPv6 support in the next release, and wait for Asus to fix it on their end.
I have been able to use ipv6 with inadyn on the router with dynv6 for a while now. The catch is I had to make two separate instances inside inadyn. One that handles the ipv4 address update and one that handles the ipv6. Maybe asus hasn't caught on yet. It took me a early morning coffee break.
 
@RMerlin

Thanks for the new Beta. Just like to report a Small OpenVPN Connection Status issue.

VPN -> VPN Status Tab -> OpenVPN Server 1
All is well and good, showing both Clients and Routes correctly.
View attachment 37844

However,
VPN - VPN Server Tab - > VPN Server - OpenVPN -> Connection Status
Is shown as Disconnected for the same Client

View attachment 37845

PS:
  • I have IPV6 (Native) setup and running correctly based on https://ipv6-test.com on my MacBookPro.
  • However, On my MacBookPro with Tunnelblick 3.8.8beta02 (build 5780), the OpenVPN connection over my iPhone Cellular Hotspot, https://ipv6-test.com ... shows there is no IPv6, only IPv4
  • What else can I test on OpenVPN and IPv6? if you can give me specific instructions. I can do the tests. Thanks.
It does not route ipv6 internet. It only connects you to the ipv6 network on your router. If you can ping ipv6 clients while connected to the tunnel, then it should be working.
 
Make sure you don't interfere with the router trying to ping the Microsoft server used to determine if the connection is up.

dnsmasq only supports nettle. @themiron implemented OpenSSL support to it in a dnsmasq fork, and we were initially hoping that Simon might eventually adopt it in the official dnsmasq release. It didn't happen, and since the OpenSSL implementation is quite complex, it meant every time a new dnsmasq release was issued, I had to wait for themiron to update his fork and adapt his patches to the new code. Since he no longer has the time to regularly keep it up-to-date due to his new job, I didn't want to get locked out of critical dnsmasq updates, and decided to simply switch back to the stock dnsmasq code. Otherwise 386.4 would still be stuck with 2.84.

You and theMiron did some great work incorporating openssl with dnsmasq back when DoT was added in to asuswrt-merlin. I can understand Simon's reluctance to incorporate openssl. The next step could have been users asking to incorporate more features to dnsmasq that leveraged more of openssl potential. ( not like that is necessarily a bad thing though).
 
Is anyone else having issues accessing LAN devices when connected to the OpenVPN Server? Historically I've had no issues with final releases (except the last one which had a SHA issue).

VPN Server setup with 'Both' selected for what the client is accessing (Internet and LAN).
All default settings except I've selected 'Yes' for 'Advertise DNS to clients' and changed the default VPN subnet to 10.10.10.0 to avoid conflicts with IP addresses. Home network is on 192.168.1.0/24

I can connect to the VPN from an android device using OpenVPN for Android and also OpenVPN Connect. No access to LAN clients via Chrome but I can access the internet over the VPN tunnel without issue.
 
Running on ax86u, it seems the wifi survey for 5Ghz doesn't work. "Unable to perform scan.Showing cached results" It works on 2.4Ghz though.
 
Is anyone else having issues accessing LAN devices when connected to the OpenVPN Server? Historically I've had no issues with final releases (except the last one which had a SHA issue).

VPN Server setup with 'Both' selected for what the client is accessing (Internet and LAN).
All default settings except I've selected 'Yes' for 'Advertise DNS to clients' and changed the default VPN subnet to 10.10.10.0 to avoid conflicts with IP addresses. Home network is on 192.168.1.0/24

I can connect to the VPN from an android device using OpenVPN for Android and also OpenVPN Connect. No access to LAN clients via Chrome but I can access the internet over the VPN tunnel without issue.
Is your ipsec server enabled? I think it also uses 10.10.10.0 by default.
 
Smooth update from alpha3 to beta1 on AX88u.
All looking good here :)
Thanks RMerlin
 
Is anyone else having issues accessing LAN devices when connected to the OpenVPN Server? Historically I've had no issues with final releases (except the last one which had a SHA issue).

VPN Server setup with 'Both' selected for what the client is accessing (Internet and LAN).
All default settings except I've selected 'Yes' for 'Advertise DNS to clients' and changed the default VPN subnet to 10.10.10.0 to avoid conflicts with IP addresses. Home network is on 192.168.1.0/24

I can connect to the VPN from an android device using OpenVPN for Android and also OpenVPN Connect. No access to LAN clients via Chrome but I can access the internet over the VPN tunnel without issue.
That's a known issue. Had it with IP cameras and VPN server and solution was one script from this forum. Try searching forum for script which enables access to cameras in LAN via openvpn server.

EDIT: https://www.snbforums.com/threads/h...outbound-connections.38086/page-2#post-314785
Found it in history of my posts.
 
That's a known issue. Had it with IP cameras and VPN server and solution was one script from this forum. Try searching forum for script which enables access to cameras in LAN via openvpn server.

EDIT: https://www.snbforums.com/threads/h...outbound-connections.38086/page-2#post-314785
Found it in history of my posts.
Thanks, I'll give it a shot! It use to work but maybe that's because OpenVPN wasn't quite right before this release. Would be good to have the LAN and Both radio button allow this without the need for a script but happy to use one if needed.
 
Thanks, I'll give it a shot! It use to work but maybe that's because OpenVPN wasn't quite right before this release. Would be good to have the LAN and Both radio button allow this without the need for a script but happy to use one if needed.
No extra script needed, working fine here. I can access both the WAN and any of my LAN devices through the OpenVPN connection, on Android or laptops from outside my LAN.
This has been the case for a least the last couple of years that I have been using this function, no helper scripts needed.
Maybe reset your OpenVPN server settings to defaults, and reconfigure from scratch.
 
No extra script needed, working fine here. I can access both the WAN and any of my LAN devices through the OpenVPN connection, on Android or laptops from outside my LAN.
This has been the case for a least the last couple of years that I have been using this function, no helper scripts needed.
Maybe reset your OpenVPN server settings to defaults, and reconfigure from scratch.
Yes, now I remembered why script was used. I wanted to BLOCK Internet access for cameras but still be able to access them via VPN server. When you block Internet access to LAN IP, it also blocks access from VPN to that LAN IP.

Sorry, forgot what for I used that script.
 
All looks good updating from Alpha3 to Beta1 on RT-AC86U.
Thanks RMerlin!
 
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