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.
Well it happened again. Another LAN/Wifi disconnect about 12:30pm. Reboot router and all good.

strange

Aug 6 12:13:56 dnsmasq-dhcp[1180]: DHCPREQUEST(br0) 192............
Aug 6 12:13:56 dnsmasq-dhcp[1180]: DHCPACK(br0) 192.................
Aug 6 12:35:13 dnsmasq-dhcp[1180]: DHCPINFORM(br0) 10..................
Aug 6 12:35:13 dnsmasq-dhcp[1180]: DHCPACK(br0) 10.........................
Aug 6 12:35:13 dnsmasq-dhcp[1180]: DHCPINFORM(br0) 192...............................
Aug 6 12:35:13 dnsmasq-dhcp[1180]: DHCPACK(br0) 192...........................
Aug 6 12:35:13 dnsmasq-dhcp[1180]: DHCPINFORM(br0) 192...............................
Aug 6 12:35:13 dnsmasq-dhcp[1180]: DHCPACK(br0) 192......................................
Aug 6 12:35:32 syslog: wlceventd_proc_event(491): eth1: Deauth_ind 28:...................., status: 0, reason: Unspecified reason (1), rssi:0
Aug 6 12:35:34 syslog: wlceventd_proc_event(527): eth1: Auth 28:............................., status: Successful (0), rssi:0
Aug 6 12:35:34 syslog: wlceventd_proc_event(556): eth1: Assoc 28:..................................., status: Successful (0), rssi:0
Aug 6 12:35:34 dnsmasq-dhcp[1180]: DHCPDISCOVER(br0) 28:..................................................
Aug 6 12:35:34 dnsmasq-dhcp[1180]: DHCPOFFER(br0) 192.............................
Aug 6 12:35:34 dnsmasq-dhcp[1180]: DHCPREQUEST(br0) 192..............................
Aug 6 12:35:34 dnsmasq-dhcp[1180]: DHCPACK(br0) 192............................... ThingsTurn_3A49
reboot
Aug 6 12:36:03 syslog: wlceventd_proc_event(508): eth1: Disassoc 8C: ......................, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Aug 6 12:36:05 syslog: wlceventd_proc_event(527): eth1: Auth 8C:......., status: Successful (0), rssi:0
Aug 6 12:36:05 syslog: wlceventd_proc_event(556): eth1: Assoc 8C:........, status: Successful (0), rssi:0
Aug 6 12:36:05 dnsmasq-dhcp[1180]: DHCPDISCOVER(br0) 8c......
 
If that client is set to use the VPN and you have DNS mode set to Exclusive, then this is working as intended.
DNS mode disabled. If I set Custom to 1.1.1.1 then Cloudflare DNS gets correctly set. If I set Custom to 8.8.8.8 then the reported DNS is the VPN DNS?!
 
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.
 
DNS mode disabled. If I set Custom to 1.1.1.1 then Cloudflare DNS gets correctly set. If I set Custom to 8.8.8.8 then the reported DNS is the VPN DNS?!
Check what DNS server your VPN provider uses - some of them actually use 8.8.8.8.
 
GT-AX11000

-Update from 386.3_0 to 386.3_2
-Dirty update didn’t reset router.
-Successful update.
-Update took longer then usual in my opinion not really sure why.
-Nothing unusual in the logs, seems good! Will monitor my uptime in case it crashes.
 
Check what DNS server your VPN provider uses - some of them actually use 8.8.8.8.
That is what I was thinking maybe they use the same servers. Or maybe the VPN provider redirects queries bound for 8.8.8.8 by substituting its own dns. I honestly don't know if this is possible though.
 
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 8th 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.
@RMerlin , I understand you are a wizard and all but is it truly August 8th where you are? :oops:;)

Edit: upgraded main router AX86u, AiMesh AC86u, and secondary location AC86U. Thanks!
 
Last edited:
Just upgraded thank you sir
 
Dirty upgrade from 386.3_0 to 386.3_2 on RT-AX3000 using RT-AX58U firmware. Also experienced a slightly longer upgrade cycle (same as DJones), but all is working well, now.
 
Dirty upgrade from 386.3_0 to 386.3-2 on my RT-AC68U
Everything works perfectly
Didn't take any extra time to upgrade, like some others have experienced
Thanks @RMerlin
 
R7000 router successfully running 384.19. Any subsequent versions will install and then tend to have at least daily LAN/Wifi disconnect on each version. I did a dirty flash first for each version I upgraded to and had reboot issues. Then performed a system default for each version and formatted the JFFS partition multiple times. In all versions past 384.19 I get random disconnects. Only way to fix is to reboot the router. Any assistance would be greatly appreciated. I am running CFE 1.3.0.7. Thanks John
 
R7000 router successfully running 384.19. Any subsequent versions will install and then tend to have at least daily LAN/Wifi disconnect on each version. I did a dirty flash first for each version I upgraded to and had reboot issues. Then performed a system default for each version and formatted the JFFS partition multiple times. In all versions past 384.19 I get random disconnects. Only way to fix is to reboot the router. Any assistance would be greatly appreciated. I am running CFE 1.3.0.7. Thanks John
Check this out: announcement-running-asuswrt-merlin-and-forks-on-non-asus-devices-is-illegal
 
I did a dirty upgrade from 386.3 to 386.3_2 on my RT-AX86U. Now when I try to log into the router using my username and password it says they are invalid, and eventually locks me out after repeated attempts. This happens whether I try to use any browser or the iOS app.

As far as I can tell, the router is functioning normally otherwise.

Has this happened to anyone else, and is there any way out of this aside from a reset to defaults?
 
R7000 router successfully running 384.19. Any subsequent versions will install and then tend to have at least daily LAN/Wifi disconnect on each version. I did a dirty flash first for each version I upgraded to and had reboot issues. Then performed a system default for each version and formatted the JFFS partition multiple times. In all versions past 384.19 I get random disconnects. Only way to fix is to reboot the router. Any assistance would be greatly appreciated. I am running CFE 1.3.0.7. Thanks John
Aside from the (perhaps not to you at the time) obvious that running one vendors firmware on another vendors hardware is legally frowned upon; you wont get support if you do decide to pursue that path. At least not in any vendor specific, public forum.
The Netgear R7000 and Asus RT-AC86u hardware is nearly identical which is why (after some hacking) it functions well with this firmware fork.
That said, you are on your own to determine how to get past any obstacles.

I would (without request) suggest you consider putting Netgear firmware on it or if you want a robust, open source system then give OpenWRT a look.
Its great and being open source its legit to run on your hardware.
Good luck
 
Check what DNS server your VPN provider uses - some of them actually use 8.8.8.8.
That is what I was thinking maybe they use the same servers. Or maybe the VPN provider redirects queries bound for 8.8.8.8 by substituting its own dns. I honestly don't know if this is possible though.
I use NordVPN. They offer the following DNS's: 103.86.96.100 and 103.86.99.100.

I have CleanBrowsing Family set as my WAN DNS, and I override in DNS Filter to one of the NordVPN DNS servers above for my televisions because this unblocks Netflix and Amazon Prime (otherwise these services detect use of VPN).

Otherwise the issue I experience is that if I create override for any specific device then the override works unless I set it to 8.8.8.8, in which case I see what I see reported by my television for the NordVPN DNS server.

Could this be because NordVPN itself performs some kind of redirect? Perhaps I should just issue a tcpdump -vpni on 'tun11' and check to see what IP DNS requests are getting sent to by device in question there? So long as that is 8.8.8.8 then there is nothing wrong with DNS Filter.
 
386.3_2 -> easy on a calm Saturday morning! Thanks Merlin team!
 
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