What's new

Beta Asuswrt-Merlin 386.2 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.
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.
 
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.
 
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.
 
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.
 
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:
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.
 
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?
 
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?
 
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.
 
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.
 
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.

 
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.
 
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.
 
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?
 
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.
 
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?
 
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