What's new

Release Asuswrt-Merlin 386.3 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.
Dirty upgrade complete from 386.3 on a RT-AX88U :cool: thanks Merlin ;)

Next on my list of things to do this weekend, build my own VPN server on the above o_O
 
On my AX88U, upgrade from 386.3 to 386.3_2 without any problem.
Everything works perfectly and maximum stability.
Thanks again to Merlin and the developers :cool:
 
reboot cured my ailment, smooth and quiet on the home front.
 
Asuswrt-Merlin 386.3 is now available for all supported model. This release introduces major changes to OpenVPN client handling, and also introduces the ability to generate QR Codes to make it easier to connect your mobile clients to your Wifi network.

August 6th 386.3_2 is now available.
Code:
  - NOTE: closed down the Issue tracker on Github, as 90%
          of it was people asking for technical support,
          or failing to use the supplied submission form.
  - CHANGED: Re-disabled jitterentropy-rngd on non-HND
             models.  It kept using CPU time every two
             seconds and had a very marginal impact on
             the entropy pool (which it never could push
             above the target threshold of 1024).
  - CHANGED: Moved the "Redirect Internet traffic" setting on
             the OpenVPN Client page to the Network Settings
             section to increase its visibility, as too many
             users are forgetting to configure it.
  - CHANGED: Display "Internet traffic not redirected" instead
             of "Public IP Unknown" on the OpenVPN Client
             status display when Redirect Internet traffic
             is set to "No".
  - FIXED: Only the first OpenVPN client would be used if
           you had multiple clients connected and the first
           one had a Redirect Internet set to "No".  Now,
           setting this to "No" means that client's routing
           table will no longer get a default gateway
           configured, allowing traffic to be processed
           by other RPDB tables if there wasn't a matching
           route within that client's table.
  - FIXED: IPV6-compatible DNSFilter servers weren't
           properly configured in dnsmasq.
  - FIXED: DNSFilter client rules may get corrupted after a
           reboot.

NOTE: On first boot with 386.3, you must either force-refresh the browser page (shift-reload), or clear your browser cache. Failure to do so will prevent the new QR codes from being properly displayed, due to an old cached CSS.

The highlights of this release:

  • QR Codes can now be generated both on the Network Map (first index page of the webui), and on the Guest Network page. QR Codes are supported by iOS as well as most modern Android mobile devices (see your device's documentation for more information on how to use it) making it easier to connect to a Wifi network.
  • Introducing VPN Director, which replaces the previous per-client Policy routing rules with a centrally managed page. More details in the Wiki: https://github.com/RMerl/asuswrt-merlin.ng/wiki/VPN-Director.
  • OpenVPN routing handling was rewritten, allowing the implementation of VPN Director, but also bringing additional fixes and improvements. Routes are now created by the firmware itself rather than by the OpenVPN process.
  • OpenVPN DNS handling was revised, resolving various quirks and issues related to it
  • Improved OpenVPN kill switch behavior, it can now be used with clients set to route All traffic through
  • Component updates: nano (5.7), curl (7.76.1), dnsmasq (2.85-openssl), openvpn (2.5.3), getdns (1.7.0), stubby (0.4.0)

Please review the Changelog for more details.

Please keep discussions to this specific release. This thread will be locked after a while once the release feedback has died down.

Downloads are here.
Changelog is here.

Thanks for moving the settings "Redirect Internet traffic" and "Killswitch". It's nice to not have to scroll down to see them.

It also puts the settings that one most likely wants to change in the same section.
 
I asked NordVPN and they say they don't redirect 8.8.8.8 DNS queries. Can anyone try setting DNS filter to custom 8.8.8.8 and see whether that DNS server gets used correctly? For me if I set to 1.1.1.1 I see Cloudflare reported correctly on dnsleaktest but if I set 8.8.8.8 I see my VPN DNS reported (I have VPN DNS accept disabled but have VPN DNS set as custom 1).
 
Updated our AX88U no problems to report

Well that’s it for the AX88U & I next month we’re moving over to pfSense Plus architecture. Really have appreciated all the hard work you all put into this project and I hope it continues to a very strong community

Thank you Eric Sauvageau
 
Here to report an effortless and flawless polluted u/g to 386.3_2 (and one or more of the most recent previous). Also installed develop scMerlin after comments here about the system map, also with no prob. One observation: I'm not seeing the gui pages for scMerlins or for another add on (this is fairly old now but I've not gotten around to it yet), vnstat iirc but don't quote me, so I have a little work to do. Awesome f/w and add ons. Thank you all very much.
 
I asked NordVPN and they say they don't redirect 8.8.8.8 DNS queries. Can anyone try setting DNS filter to custom 8.8.8.8 and see whether that DNS server gets used correctly? For me if I set to 1.1.1.1 I see Cloudflare reported correctly on dnsleaktest but if I set 8.8.8.8 I see my VPN DNS reported (I have VPN DNS accept disabled but have VPN DNS set as custom 1).
Yes I can confirm this behaviour with NordVPN and 8.8.8.8 and 8.8.4.4. I have compared the routing and iptables rules in various scenarios. I've even turned off DNSFilter and manually created my own DNS DNAT rules. Everything points to this being a DNS interception by the NordVPN server (London) I'm connected through.
 
Yes I can confirm this behaviour with NordVPN and 8.8.8.8 and 8.8.4.4. I have compared the routing and iptables rules in various scenarios. I've even turned off DNSFilter and manually created my own DNS DNAT rules. Everything points to this being a DNS interception by the NordVPN server (London) I'm connected through.
Thanks for confirming. Just wanted to check it wasn't an issue with the firmware. Weird that they do that, right?
 
Lotta filthy upgrades happening... love it.
 
Had good uptime on 386.3. Upgraded to 386.3_2 this morning and all seemed to be going well. Noticed the router restarted preceded by this message:
Code:
Aug  7 18:27:42 kernel: CONSOLE: 175295.097 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:28:07 kernel: CONSOLE: 175320.014 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:28:42 kernel: CONSOLE: 175354.699 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:29:07 kernel: CONSOLE: 175379.618 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:29:42 kernel: CONSOLE: 175414.400 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:30:07 kernel: CONSOLE: 175439.216 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:30:42 kernel: CONSOLE: 175474.001 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:31:07 kernel: CONSOLE: 175498.815 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:31:42 kernel: CONSOLE: 175533.598 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:32:07 kernel: CONSOLE: 175558.415 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:32:42 kernel: CONSOLE: 175593.200 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
Aug  7 18:33:07 kernel: CONSOLE: 175618.015 wl1: wlc_ampdu_recv_addba_resp: 38:81:d7:3d:3f:f0: Failed. status 37 wsize 32 policy 1
May  5 01:05:08 syslogd started: BusyBox v1.25.1
May  5 01:05:08 kernel: klogd started: BusyBox v1.25.1 (2021-08-06 17:47:26 EDT)

Had about 23 minutes of the above before the crash.
Have PnP disabled, WPS disabled, DoT and DNSSEC enabled, FlexQOS enabled, AiProtect enabled. 5 GHz @ 160 MHZ on CH 36, 2.4 GHz @ 20 MHz on CH 11, SmartConnect, WPA2/WPA3, Guest 2 enabled 2.4 GHz @ WPA2
 
Weird that they do that, right?
I'm not entirely sure that's what's happening but I can't think of another explanation as there doesn't seem to be anything special about those IP addresses in the router's configuration.
 
I'm not entirely sure that's what's happening but I can't think of another explanation as there doesn't seem to be anything special about those IP addresses in the router's configuration.
I did ask NordVPN on support chat and the representative I spoke with said that she did not think any such redirection on 8 8.8.8 was applied by NordVPN. RMerlin uses NordVPN too. Maybe he has some idea.
 
I did ask NordVPN on support chat and the representative I spoke with said that she did not think any such redirection on 8 8.8.8 was applied by NordVPN. RMerlin uses NordVPN too. Maybe he has some idea.
I only tried it with one NordVPN server. Maybe you can try a few different ones and see if they all behave the same.
 
Dirty upgrade last night to AiMesh node. All is superb.
Dirty upgrade to router this morning. All is superb.
Rebooted both machines after 1 hour of uptime.

Thanks @RMerlin and all contributors and testers.
 
AX86U dirty upgrade to 386.3_2 from 386.3, no initial problems.
 
AC86U dirty upgrade to 386.3_2 from 386.3 and noticed the below log entry:

Aug 8 10:25:59 kernel: protocol 0800 is buggy, dev eth5

It is repeating itself in the log.

Any idea?
 
AC86U dirty upgrade to 386.3_2 from 386.3 and noticed the below log entry:

Aug 8 10:25:59 kernel: protocol 0800 is buggy, dev eth5

It is repeating itself in the log.

Any idea?
 
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