Beta Asuswrt-Merlin 386.2 Beta is now available

Status
Not open for further replies.

Wade Coxon

Senior Member
Things are relatively smooth with this beta on my rt-ac86u, except I am losing my connection after 24-48 hours after a reboot.

The last disconnection was accompanied by the following log entries:

Code:
Mar 16 15:20:06 Mastiff: Got SIGTERM
Mar 16 15:20:12 lldpd[9076]: cannot get ethtool link information with GLINKSETTINGS (requires 4.9+): Operation not permitted
Mar 16 15:20:12 lldpd[9076]: cannot get ethtool link information with GSET (requires 2.6.19+): Operation not permitted
Mar 16 15:20:13 kernel: ^[[0;33;41m[ERROR mcast] bcm_mcast_netlink_process_snoop_cfg,884: interface 20 could not be found^[[0m
Mar 16 15:20:13 kernel: ^[[0;33;41m[ERROR mcast] bcm_mcast_netlink_process_snoop_cfg,884: interface 20 could not be found^[[0m

I do have multicast snooping enabled on my wireless interfaces. That's all I can glean from this.
 

askan7

Regular Contributor
Try tweaking your overhead settings, these are critical when dealing with small packets.
I did, nothing works. Also I used this to get the right overhead: https://github.com/moeller0/ATM_overhead_detector

I have to learn how to use wireshark and see if this really affects latency or just the icmp packets sent by the tests I'm running as the games don't show these ping spikes.
 

joe scian

Very Senior Member
I’m going to give Cake QOS a try but I’m struggling to find instructions on what to set the MPU to under the WAN packet overhead - what does this do? Can it be left at the default 0?

Thanks,

HB
yes - some say 64 - however I have found 0 works just fine.
 

Catalinus

Occasional Visitor
Has somebody tested latest OpenVPN over TCP in a configuration with encrypted TLS control channel with more than 2 clients at the same time? (the one other non-standard setting is port 443 instead of 1194). It works fine with one client but the moment a 2nd client connects the first one is thrown out (which in turn after some time tries to reconnect, does indeed reconnect and throws out the other client and so on). That is happening with basically any type of client - Windows, MacOS, Android, iOS.

384.18 was the last version where that worked OK and I was hoping that things will get better with the new version.
 

JIPG

Regular Contributor
Set it manually instead of relying on the timezones. It's possible that the router's TZ database isn't up to date, with all the changes that happened these past few years to DST periods.
How can I set the time (or TZ) manually?. Correct me if I am wrong, but DST application is automatic (there is no way in the GUI to select or deselect it). Then, I can only select the TZ (to know the time displacement regarding GMT) and later manually establish the start and finish of DST. I have selected manually TZ and DST application dates, so i do not know if you refer to any of them or both.

In my case, there are several TZ in Europe with the same hour, and they follow same approach from too many years ago. If I apply my "correct" TZ (Madrid, GMT+1), I have now wrong time (even without reaching the DST change date). I have checked and the problem could be the "formal" name in the FW for the time zone (MET-1DST_1), as it has an underscore character. If I change TZ to (Amsterdam GMT+1), the time is correct (even the warning "the system time zone is different from my locale setting" disappeared). Curiously, the "formal" name of (Amsterdam GMT+1) is MEZ-1DST (no underscore), so probably the commit introduced in 386.2 beta will solve it. Nevertheless, [B]FTC[/B] has reported that in 386.2 beta the time shows correct but the warning "the system time zone is different from my locale setting" is still present.

At the moment, my workaround in 386.1_2 is to select TZ (Amsterdam GMT+1), as it neither produce time deviation nor warning "the system time zone is different from my locale setting". DST change dates remain as before (in CE we change the hour at the same time). So my recommendation, until 386.2 is finished is to use a different TZ (with the same GMT increment) until the wrong time problem dissapears.
 

shauno100

Occasional Visitor
The same fix will apply to all models, it's not model specific.

You need to check the content of /tmp/filter_rules to determine whether or not it is really the same issue.


No, it's not a bug, and it's nothing new to 386.2 beta either. Already debated to death in previous releases.
Using 386.2 beta1, Using a custom DNS server on the WAN config page (Connect to DNS Server automatically) = unchecked, internet not working , the contents of /tmp/filter_rules on my RT-AX58U are below

As mentioned when i check the "Connect to DNS Server automatically" option to use ISP DNS instead the internet starts working again. Also rolling back to official 386.1_2 release gets my internet working with my custom DNS server applied.



Code:
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:INPUT_PING - [0:0]
:INPUT_ICMP - [0:0]
:FUPNP - [0:0]
:SECURITY - [0:0]
:ACCESS_RESTRICTION - [0:0]
:ICAccept - [0:0]
:ICDrop - [0:0]
:other2wan - [0:0]
:OVPN - [0:0]
:DNSFILTER_DOT - [0:0]
:NSFW - [0:0]
:PControls - [0:0]
:default_block - [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
:PTCSRVWAN - [0:0]
:PTCSRVLAN - [0:0]
-A INPUT -p icmp --icmp-type 8 -j INPUT_PING
-A INPUT_PING -i eth4 -p icmp -j logdrop
-A INPUT -m state --state RELATED,ESTABLISHED -j logaccept
-A INPUT -m state --state INVALID -j logdrop
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp --sport 67 --dport 68 -j logaccept
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT_ICMP -p icmp --icmp-type 8 -j RETURN
-A INPUT_ICMP -p icmp --icmp-type 13 -j RETURN
-A INPUT_ICMP -p icmp -j logaccept
-A INPUT -j logdrop
-A FORWARD -m state --state ESTABLISHED,RELATED -j logaccept
-A FORWARD -o eth4 ! -i br0 -j other2wan
-A other2wan -i tun+ -j RETURN
-A other2wan -j logdrop
-A FORWARD -i br0 -o br0 -j logaccept
-A FORWARD -m state --state INVALID -j logdrop
-A FORWARD -i eth4 -j SECURITY
-A FORWARD -j NSFW
-A ICAccept -j logaccept
-A ICDrop -j logdrop
-A PControls -j logdrop
-A FORWARD -i br0 -j logaccept
-A FORWARD -m conntrack --ctstate DNAT -j logaccept
-A FORWARD -m state --state NEW -j OVPN
-A SECURITY -p tcp --syn -m limit --limit 1/s -j RETURN
-A SECURITY -p tcp --syn -j logdrop
-A SECURITY -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j RETURN
-A SECURITY -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j logdrop
-A SECURITY -p icmp --icmp-type 8 -m limit --limit 1/s -j RETURN
-A SECURITY -p icmp --icmp-type 8 -j logdrop
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
-A FORWARD -j logdrop
COMMIT
 
Last edited:

Adreno

Occasional Visitor
Using 386.2 beta1, Using a custom DNS server on the WAN config page (Connect to DNS Server automatically) = unchecked, internet not working , the contents of /tmp/filter_rules on my RT-AX58U are below

As mentioned when i check the "Connect to DNS Server automatically" option to use ISP DNS instead the internet starts working again. Also rolling back to official 386.1_2 release gets my internet working with my custom DNS server applied.

I've reported the same problem, but I still don't know if is something related with "Asus recent DNS routing changes" or just a bug.

I've had to also rollback to 386.1_2.
 

shabbs

Senior Member
Using 386.2 beta1, Using a custom DNS server on the WAN config page (Connect to DNS Server automatically) = unchecked, internet not working , the contents of /tmp/filter_rules on my RT-AX58U are below

As mentioned when i check the "Connect to DNS Server automatically" option to use ISP DNS instead the internet starts working again. Also rolling back to official 386.1_2 release gets my internet working with my custom DNS server applied.
What custom DNS server are you using for your WAN DNS?
 

shabbs

Senior Member
I am using a LAN based DNS server (Synology NAS) which i have used with no issue for years, only in this recent 386.2 release has it stopped working.
So it's an internal DNS entry then. This Asus change seems to affect setups that are using an internal DNS reference on the WAN DNS.

Any particular reason to use an internal DNS entry for your WAN DNS?
 

shauno100

Occasional Visitor
So it's an internal DNS entry then. This Asus change seems to affect setups that are using an internal DNS reference on the WAN DNS.

Any particular reason to use an internal DNS entry for your WAN DNS?
It appears so. No just how i have had my network setup for ages. I'd rather all DNS handling be performed by my NAS that's all.
 

lilstone87

Senior Member
What ip (10.218.0.1) is that? I can't test it.

He's on cable(docsis) internet. The first hop outside his home network, is the CMTS(CCAP). That IP is only pingable by him, and likely the ISP themselves. It's not reachable to the outside world.

As for the issue he's seeing while gaming, when I had cake enabled during the alpha, and I was playing COD CW, I noticed a couple times over a couple different games. The connection would get jerky, as if latency spiked, or such. Overall the issue wasn't at the home, or the internet connection itself. It's something with cake being a bit funny. As we all know, gaming doesn't use a lot of bandwidth, but it does send a good amount of smaller packets every second.

Overall I would love to see a group of us on here, test cake while online gaming, especially for shooter type games, where connection is very important to keep steady. I do think cake is a good option to use, even for gamers. However I do think the "default" settings, might not be best option for us gamers. So it's a matter of some testing being done, and I think it needs to happen with a couple/few of us on here.
 

GHammer

Senior Member
It appears so. No just how i have had my network setup for ages. I'd rather all DNS handling be performed by my NAS that's all.
There is a way to force the issue of using a particular DNS server and I use it here for my pihole.
One of the things is that whatever you have in the WAN DNS is reversed, uses entry 2 instead of 1. Mine is set for a public server 1st pihole 2nd. Pihole gets the call everytime and I have had no issue with using an internal DNS server on this or any builds.

Look at post 3 from the illustrious Dave14305.

 

shauno100

Occasional Visitor
There is a way to force the issue of using a particular DNS server and I use it here for my pihole.
One of the things is that whatever you have in the WAN DNS is reversed, uses entry 2 instead of 1. Mine is set for a public server 1st pihole 2nd. Pihole gets the call everytime and I have had no issue with using an internal DNS server on this or any builds.

Look at post 3 from the illustrious Dave14305.

I just tested what you suggested with 8.8.8.8 as WAN DNS entry 1 and my NAS IP as DNS 2 but still no internet connectivity. Only way i can get internet connectivity is by checking the "Connect to DNS Server automatically" option.
 

shabbs

Senior Member
It appears so. No just how i have had my network setup for ages. I'd rather all DNS handling be performed by my NAS that's all.
Understood. Not sure if Asus is going to keep that setup or look to provide a better toggle to recognized that the entries are internal and to ensure static routes are setup properly.

For my setup, I have Quad9 DNS servers listed in the WAN DNS entries and my two LAN Pi-holes listed as the DNS servers in the LAN DHCP entries. DNSFilter is enabled and set to "Router" so that any hard coded DNS entries by IOT devices are forced to route through my Pi-holes. Any static assignments have manual DNS entries pushed out specifying the Pi-hole DNS entry.
 

Chuckles67

Regular Contributor
Has somebody tested latest OpenVPN over TCP in a configuration with encrypted TLS control channel with more than 2 clients at the same time? (the one other non-standard setting is port 443 instead of 1194). It works fine with one client but the moment a 2nd client connects the first one is thrown out (which in turn after some time tries to reconnect, does indeed reconnect and throws out the other client and so on). That is happening with basically any type of client - Windows, MacOS, Android, iOS.

384.18 was the last version where that worked OK and I was hoping that things will get better with the new version.
I had similar issue with several remote clients connecting simultaneously to OpenVPN Server with UDP 1194: what worked for me was to add an extra line to the OpenVPN Server custom configuration (link):
Code:
username-as-common-name
Hit Apply, and export the new .ovpn configuration and use in the clients. Maybe this will work for you?
 

shauno100

Occasional Visitor
I should also mention my Synology NAS is used for both DHCP and DNS on my LAN, i have disabled DHCP server on router. Guessing i have a very unique use-case that's unfortunately affected by Asus changes. May need to adjust my setup, i have not used DNSFilter to be honest.
 

shabbs

Senior Member
I should also mention my Synology NAS is used for both DHCP and DNS on my LAN, i have disabled DHCP server on router. Guessing i have a very unique use-case that's unfortunately affected by Asus changes. May need to adjust my setup, i have not used DNSFilter to be honest.
Location of the DHCP server should not really be a factor, I don't think. What DNS entry is your DHCP handout giving out?
 

RMerlin

Asuswrt-Merlin dev
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