What's new

[Release] Asuswrt-Merlin 384.12 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!

Updated to 384.12 on RT-AC66U
QoS is off and apps analysis is off.
Should QoS - WAN/LAN Bandwidth Monitor still show Upload Bandwidth and Download Bandwidth even if Apps analysis is off?
 
Updated to 384.12 on RT-AC66U
QoS is off and apps analysis is off.
Should QoS - WAN/LAN Bandwidth Monitor still show Upload Bandwidth and Download Bandwidth even if Apps analysis is off?

Yes
 
Not sure what happened this morning with my 87U on .12, but at 8am it was unresponsive and wireless connections failed, probably because no DHCP addresses were being obtained (strong wireless signal though). I've posted the TL;DR log below, with a sequence of messages I haven't seen before. At 6:06am all was well. At 6:28 something happened, and at 6:58 the router froze. The reboot in the last line was me unplugging the router at 8:00am.

There is nothing in the DNSmasq or pixelserv logs after normal messages at 6:25. There is no chron job set to run at that time. (My last clean install was 11.2, so no, I haven't gone through a clean install process, not having had any issue until this).

Code:
Jul  3 05:20:22 RT-AC87R Diversion: rotated dnsmasq log files, from /opt/share/diversion/file/rotate-logs.div
Jul  3 05:35:58 RT-AC87R kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jul  3 06:06:00 RT-AC87R kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jul  3 06:28:30 RT-AC87R kernel: 92      503        0   0       0             0 sh
Jul  3 06:28:30 RT-AC87R kernel: [ 4894]     0  4894      503        0   0       0             0 sh
Jul  3 06:28:30 RT-AC87R kernel: [ 4896]     0  4896      503        0   1       0             0 sh
Jul  3 06:28:30 RT-AC87R kernel: [ 4910]     0  4910      503        0   1       0             0 sh
Jul  3 06:28:30 RT-AC87R kernel: [ 4912]     0  4912      503        0   0       0             0 sh
Jul  3 06:28:30 RT-AC87R kernel: [ 4913]     0  4913      353        0   0       0             0 grep
Jul  3 06:28:30 RT-AC87R kernel: [ 4914]     0  4914      503        0   0       0             0 sh
Jul  3 06:28:30 RT-AC87R kernel: [ 4915]     0  4915      354        0   0       0             0 awk
Jul  3 06:28:30 RT-AC87R kernel: [ 4916]     0  4916      353        0   1       0             0 grep
Jul  3 06:28:30 RT-AC87R kernel: [ 4917]     0  4917      354        0   0       0             0 awk
Jul  3 06:28:35 RT-AC87R kernel: [ 4918]     0  4918      503        0   0       0             0 sh
Jul  3 06:28:35 RT-AC87R kernel: [ 4919]     0  4919      353        0   1       0             0 grep
Jul  3 06:28:35 RT-AC87R kernel: [ 4920]     0  4920      354        0   1       0             0 awk
Jul  3 06:28:35 RT-AC87R kernel: [ 4921]     0  4921      503        0   0       0             0 sh
Jul  3 06:28:35 RT-AC87R kernel: [ 4924]     0  4924      503        0   0       0             0 sh
Jul  3 06:28:35 RT-AC87R kernel: [ 4928]     0  4928      503        0   1       0             0 sh
Jul  3 06:28:35 RT-AC87R kernel: [ 4929]     0  4929      503        0   0       0             0 sh
Jul  3 06:28:35 RT-AC87R kernel: [ 4930]     0  4930      353        0   0       0             0 grep
Jul  3 06:28:35 RT-AC87R kernel: [ 4932]     0  4932      355        0   1       0             0 nslookup
Jul  3 06:28:35 RT-AC87R kernel: [ 4933]     0  4933      353        0   1       0             0 grep
Jul  3 06:28:45 RT-AC87R kernel: [ 4935]     0  4935      354        0   1       0             0 awk
Jul  3 06:28:45 RT-AC87R kernel: [ 4938]     0  4938      357        0   1       0             0 sed
Jul  3 06:28:45 RT-AC87R kernel: [ 4939]     0  4939      354        0   1       0             0 awk
Jul  3 06:28:45 RT-AC87R kernel: [ 4940]     0  4940      503        0   0       0             0 sh
Jul  3 06:28:45 RT-AC87R kernel: [ 4947]     0  4947      503        0   1       0             0 sh
Jul  3 06:28:45 RT-AC87R kernel: [ 4949]     0  4949      503        0   1       0             0 sh
Jul  3 06:28:45 RT-AC87R kernel: [ 4950]     0  4950      354        0   1       0             0 awk

<I've truncated this, a hundred lines all more of the same>
Jul  3 06:58:16 RT-AC87R kernel: [ 5241]     0  5241      503        0   1       0             0 sh
Jul  3 06:58:16 RT-AC87R kernel: [ 5242]     0  5242      503        0   0       0             0 sh
Jul  3 06:58:16 RT-AC87R kernel: Out of memory: Kill process 199 (nt_monitor) score 1 or sacrifice child
Jul  3 06:58:16 RT-AC87R kernel: Killed process 207 (nt_monitor) total-vm:5060kB, anon-rss:0kB, file-rss:0kB
Jul  3 06:58:34 RT-AC87R kernel: tdts_core_ioctl_udb_op_prog_ctrl() fail!
Jul  3 06:58:34 RT-AC87R syslog: hotplug2 terminated unexpectedly, restarting.
May  5 01:05:02 syslogd started: BusyBox v1.25.1
 
I was wondering why infuse on apple tv wouldnt connect to the NAS any longer, thought it was a NAS update that caused the issue, so thanks for sharing.
I at first thought it was windows 10 on my end since Microsoft put out a update that turned samba off but i remembered i had turned it back on for my freenas shares.

Something got broken clearly if this is happening cross platform and i am sure Eric already working on it.

For now i went back to 11 to avoid the problem tell he finds the bug.
 
After 17 hours (almost 18)
The router acts really strange, on the wireless phones.
It says it lost internet connection (it actually does lose connection to the internet)
But once you turn off and on the wifi, it reconnects and works fine.
It has happened ever since V384.10
And now it's still happening on V384.12

Below you can see my stats, the last 17 hours (only a few mins, is from logging EVERYTHING.
But other than that, it's just been on "notice"

(And yes, i did do a factory reset, for 17 hours ago.)
But it is still happening.

0 days 17 hours 54 minutes 28 seconds
 

Attachments

  • syslog.txt
    333.1 KB · Views: 570
ProtonVPN client no longer works on 384.12 and hangs indefinitely while attempting to connect. "Error check configuration"
Changing new Inbound Firewall settings to Allow/Block have no effect.
I have both ProtonVPN and PIA running on 384.12. See if there is more detail in the log and adjust settings accordingly.
 
With the new release 384.12 what is the expected behaviour when connected over VPN and this tunnel goes down?
In my specific setup I have no values entered under WAN DNS. What I think should happen is that when my VPN connection goes down all my connected devices should loose access to internet.
However, I am noticing that when that happens all connected clients get ISP dns and connections are open. Is that a desired behaviour?
 
With the new release 384.12 what is the expected behaviour when connected over VPN and this tunnel goes down?
In my specific setup I have no values entered under WAN DNS. What I think should happen is that when my VPN connection goes down all my connected devices should loose access to internet.
However, I am noticing that when that happens all connected clients get ISP dns and connections are open. Is that a desired behaviour?
What do you have under Advanced settings for the VPN connection?? Specifically "Block routed clients if tunnel goes down?"

upload_2019-7-3_15-14-22.png
 
Option below all that. The one regarding what to do when the vpn tunnel goes down.


Sent from my iPhone using Tapatalk
 
For some reason the router (88U) GUI interface has become to a slow, grinding experience. It's that way with any browser I use, though Firefox is the slowest. This seems to have occurred since the last Windows 10 update (Tuesday, July 2nd), though that's just anecdotal.

Any thoughts?
Anton
 
That option is not available if you select All.
Since that option doesn't come up with All then I wouldn't think that option would default to blocking them. May need to ping @RMerlin to get his thoughts....
 
You need to create the file /jffs/scripts/stubby.postconf

You can do this with WinSCP. Navigate to /jffs/scripts. Right click in the right window and select New/File or Shift + F4. Name the file stubby.postconf and enter the following (just copy and paste):
Code:
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_replace "idle_timeout: 9000" "idle_timeout: 2000" $CONFIG
pc_replace "tls_connection_retries: 2" "tls_connection_retries: 5" $CONFIG
pc_replace "timeout: 3000" "timeout: 2000" $CONFIG
pc_replace "round_robin_upstreams: 1" "round_robin_upstreams: 0" $CONFIG
Save the file. Right click on the file and check the boxes next to the three X's to make the Octal:755 then click OK. Restart Stubby by turning DoT off then on or in a terminal session with
service restart_stubby

These settings seem to help at least on my ISP. I have found Cloudflare to be the most reliable for me with CleanBrowsing next then Quad9. I manage a couple of routers on another ISP and Quad9 seems to work better than Cloudflare. I feel it is how the DNS resolver anycast addresses are routed. The closest Quad9 data center to me is 100 miles away as the crow flies but I get routed to another Quad9 data center 1,000 miles away and have been routed to the Quad9 data center clear across the country on the west coast! Using Cloudflare I'm routed to the data center 100 miles away. Also feel that DNSSEC is handled better by Cloudflare.

Thanks for the information.... question...can you do the instructions posted only when using cloudflare or any DNS server i.e. Quad9??
 
Thanks for the information.... question...can you do the instructions posted only when using cloudflare or any DNS server i.e. Quad9??
Any. I have a couple of AC68U's on a cable provider that I recently switched from Cloudflare to Quad9. My home router has been on several other providers but Cloudflare seems to be the best.

Sent from my SM-T380 using Tapatalk
 
That option is not available if you select All.
For those who prefer to route all LAN traffic to the VPN, enabling the “Policy Rules” or “Policy Rules (Strict)” setting enables the option to “Block routed clients if tunnel goes down” to be displayed. Enabling this option will allow you to block LAN traffic from traversing to the WAN interface if the VPN tunnel goes down.

To enable the Policy Rule feature in Asuswrt-Merlin firmware, set “Redirect Internet traffic” to “Policy Rules” or “Policy Rules (Strict)” in the OpenVPN Client Screen. Policy Rules (Srtict) mode will take additional steps to ensure there aren’t any extra routes that could potentially bypass the VPN tunnel by only allowing routes that specifically target the VPN tunnel’s network interface. The Policy Rules (Srtict) mode is the preferred setting.

Once you enable Policy Rules, a new section will appear below, where you can add routing rules. The “Source IP” is a local LAN Client device, such as a laptop or mobile phone. “Destination” is a remote server on the Internet. The “Destination” field can be left empty, or set to 0.0.0.0 to signify any IP address. You can also specify a whole subnet in CIDR notation. For example, 74.125.226.112/30.

A common configuration where you want your entire LAN to go through the VPN, but not the router itself:

Code:
LAN_IPs    192.168.1.0/24    0.0.0.0    VPN
Router      192.168.1.1     0.0.0.0     WAN

“Accept DNS Configuration” set to “Disabled”

The disadvantage of setting “Accept DNS configuration” to “Exclusive” is that DNSMASQ will be bypassed since the VPN tunnel will exclusively use the DNS of the VPN Provider. The popular Diversion ad blocker program, written for the Asuswrt-Merlin firmware, will not work since Diversion requires the features of DNSMASQ. Diversion will work over the VPN tunnel when “Accept DNS configuration” is set to “Exclusive” and Policy Rules are disabled by setting “Redirect Internet Traffic” to “All”.


My preferred setting is to set “Accept DNS Configuration” to “Disabled” and install Stubby DNS over TLS. Stubby DNS over TLS will encrypt DNS queries for all devices on the network. This setting also allows the Diversion ad blocker to work over the VPN tunnel.
 
Last edited:
I have been using this Rounter and Merlin for almost 2 years. Love you guys for keeping this device up and running. Am facing a problem for upgrading 384.6 to latest 384.12 but never reflected the update.
Tried the traditional way of uploading the .trx file under upload latest firmware upload.
can someone help me on this issue ?
 
I have been using this Rounter and Merlin for almost 2 years. Love you guys for keeping this device up and running. Am facing a problem for upgrading 384.6 to latest 384.12 but never reflected the update.
Tried the traditional way of uploading the .trx file under upload latest firmware upload.
can someone help me on this issue ?
Unplugging all USB devices, and give it a reboot and try again, aslo which model?
 

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