Release Asuswrt-Merlin 384.19 is now available

[kabuto]

forgive me for my translator english
I have a problem with dns over tls, I can't get it to go through port 853, doing a tcpdump I only see requests to port 53.

This is my setup

I don't know what else to look at, I have skynet and diversion, the ads are blocked fine, but I see no request going through port 853


cat /tmp/resolv.conf
nameserver 1.1.1.1
nameserver 127.0.1.1

/jffs/scripts/dnsmasq.postconf
. /opt/share/diversion/file/post-conf.div # Added by Diversion
/jffs/scripts/uiDivStats dnsmasq & # uiDivStats


Thank you so much for everything

 

[dave14305]

forgive me for my translator english
I have a problem with dns over tls, I can't get it to go through port 853, doing a tcpdump I only see requests to port 53.

This is my setup

I don't know what else to look at, I have skynet and diversion, the ads are blocked fine, but I see no request going through port 853


cat /tmp/resolv.conf
nameserver 1.1.1.1
nameserver 127.0.1.1

/jffs/scripts/dnsmasq.postconf
. /opt/share/diversion/file/post-conf.div # Added by Diversion
/jffs/scripts/uiDivStats dnsmasq & # uiDivStats


Thank you so much for everything

The settings look correct. What are your tcpdump command parameters? Is it capturing the WAN interface only?

 

[kabuto]

The settings look correct. What are your tcpdump command parameters? Is it capturing the WAN interface only?

--> brctl show
bridge name bridge id STP enabled interfaces
br0 8000.1cb72cdad930 yes vlan1
eth2
eth1
eth3
wl0.1



I only have traffic through the br0 interface

tcpdump -i br0 -p port 853 or 53 -n

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:57:03.243350 IP 192.168.1.248.39884 > 192.168.1.1.53: 2+ A? www.baidu.com. (31)
11:57:03.244740 IP 192.168.1.1.53 > 192.168.1.248.39884: 2 4/0/0 CNAME www.a.shifen.com., CNAME www.wshifen.com., A 104.193.88.123, A 104.193.88.77 (122)
11:57:03.492442 IP 192.168.1.252.43012 > 192.168.1.1.53: 59564+ A? cdp.cloud.unity3d.com. (39)
11:57:03.493383 IP 192.168.1.1.53 > 192.168.1.252.43012: 59564* 1/0/0 A 192.168.1.86 (55)
11:57:04.166666 IP 192.168.1.242.41858 > 192.168.1.1.53: 21370+ A? api-global.netflix.com. (40)
11:57:04.167006 IP 192.168.1.242.40221 > 208.67.222.222.53: 36055+ A? api-global.netflix.com. (40)
11:57:04.245832 IP 208.67.222.222.53 > 192.168.1.242.40221: 36055| 0/0/0 (40)
11:57:04.254065 IP 192.168.1.242.42334 > 208.67.222.222.53: Flags , seq 2864218626, win 65535, options [mss 1460,sackOK,TS val 371231198 ecr 0,nop,wscale 6], length 0
11:57:04.254281 IP 208.67.222.222.53 > 192.168.1.242.42334: Flags [S.], seq 3289314172, ack 2864218627, win 5792, options [mss 1460,sackOK,TS val 3181040 ecr 371231198,nop,wscale 4], length 0
11:57:04.259129 IP 192.168.1.242.42334 > 208.67.222.222.53: Flags [.], ack 1, win 1369, options [nop,nop,TS val 371231198 ecr 3181040], length 0
00:00:00.485726 IP 192.168.1.242.42334 > 208.67.222.222.53: Flags [P.], seq 1:43, ack 1, win 1369, options [nop,nop,TS val 371231198 ecr 3181040], length 42 36055+ A? api-global.netflix.com. (40)
11:57:04.274641 IP 208.67.222.222.53 > 192.168.1.242.42334: Flags [.], ack 43, win 362, options [nop,nop,TS val 3181043 ecr 371231198], length 0
11:57:04.275924 IP 208.67.222.222.53 > 192.168.1.242.42334: Flags [P.], seq 1:274, ack 43, win 362, options [nop,nop,TS val 3181043 ecr 371231198], length 273 36055 10/0/0 CNAME api-global.dradis.netflix.com., CNAME api-global.eu-west-1.origin.prodaa.netflix.com., A 34.243.218.179, A 34.241.157.21, A 52.210.128.148, A 52.31.250.247, A 52.210.158.159, A 34.242.137.101, A 52.16.84.15, A 34.250.49.21 (271)
11:57:04.283999 IP 192.168.1.242.42334 > 208.67.222.222.53: Flags [.], ack 274, win 1407, options [nop,nop,TS val 371231201 ecr 3181043], length 0

I find it strange to see the dns 208.67.222.222 when I do not have it anywhere
That internal ip is samsung tv

Thank you very much for the help

 

[dave14305]

--> brctl show
bridge name bridge id STP enabled interfaces
br0 8000.1cb72cdad930 yes vlan1
eth2
eth1
eth3
wl0.1



I only have traffic through the br0 interface

tcpdump -i br0 -p port 853 or 53 -n

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:57:03.243350 IP 192.168.1.248.39884 > 192.168.1.1.53: 2+ A? www.baidu.com. (31)
11:57:03.244740 IP 192.168.1.1.53 > 192.168.1.248.39884: 2 4/0/0 CNAME www.a.shifen.com., CNAME www.wshifen.com., A 104.193.88.123, A 104.193.88.77 (122)
11:57:03.492442 IP 192.168.1.252.43012 > 192.168.1.1.53: 59564+ A? cdp.cloud.unity3d.com. (39)
11:57:03.493383 IP 192.168.1.1.53 > 192.168.1.252.43012: 59564* 1/0/0 A 192.168.1.86 (55)
11:57:04.166666 IP 192.168.1.242.41858 > 192.168.1.1.53: 21370+ A? api-global.netflix.com. (40)
11:57:04.167006 IP 192.168.1.242.40221 > 208.67.222.222.53: 36055+ A? api-global.netflix.com. (40)
11:57:04.245832 IP 208.67.222.222.53 > 192.168.1.242.40221: 36055| 0/0/0 (40)
11:57:04.254065 IP 192.168.1.242.42334 > 208.67.222.222.53: Flags , seq 2864218626, win 65535, options [mss 1460,sackOK,TS val 371231198 ecr 0,nop,wscale 6], length 0
11:57:04.254281 IP 208.67.222.222.53 > 192.168.1.242.42334: Flags [S.], seq 3289314172, ack 2864218627, win 5792, options [mss 1460,sackOK,TS val 3181040 ecr 371231198,nop,wscale 4], length 0
11:57:04.259129 IP 192.168.1.242.42334 > 208.67.222.222.53: Flags [.], ack 1, win 1369, options [nop,nop,TS val 371231198 ecr 3181040], length 0
00:00:00.485726 IP 192.168.1.242.42334 > 208.67.222.222.53: Flags [P.], seq 1:43, ack 1, win 1369, options [nop,nop,TS val 371231198 ecr 3181040], length 42 36055+ A? api-global.netflix.com. (40)
11:57:04.274641 IP 208.67.222.222.53 > 192.168.1.242.42334: Flags [.], ack 43, win 362, options [nop,nop,TS val 3181043 ecr 371231198], length 0
11:57:04.275924 IP 208.67.222.222.53 > 192.168.1.242.42334: Flags [P.], seq 1:274, ack 43, win 362, options [nop,nop,TS val 3181043 ecr 371231198], length 273 36055 10/0/0 CNAME api-global.dradis.netflix.com., CNAME api-global.eu-west-1.origin.prodaa.netflix.com., A 34.243.218.179, A 34.241.157.21, A 52.210.128.148, A 52.31.250.247, A 52.210.158.159, A 34.242.137.101, A 52.16.84.15, A 34.250.49.21 (271)
11:57:04.283999 IP 192.168.1.242.42334 > 208.67.222.222.53: Flags [.], ack 274, win 1407, options [nop,nop,TS val 371231201 ecr 3181043], length 0

I find it strange to see the dns 208.67.222.222 when I do not have it anywhere
That internal ip is samsung tv

Thank you very much for the help

Port 853 will only be seen on the eth0 WAN interface. LAN interface br0 will still only show port 53.

DNSFilter should be intercepting the traffic to OpenDNS. Confirm on the eth0 Interface tcpdump.

 

[kabuto]

[QUOTE = "dave14305, publicación: 623365, miembro: 58901"]
El puerto 853 solo se verá en la interfaz WAN eth0. La interfaz LAN br0 seguirá mostrando solo el puerto 53.

DNSFilter debería estar interceptando el tráfico a OpenDNS. Confirme en la interfaz eth0 tcpdump.
[/CITAR]


there is no traffic on interface eth0


kabuto@RT-AC3200-D930:/tmp/home/root# tcpdump -i eth0 -p port 853 or 53 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes


^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Thank you

 

[Mutzli]

Use tcpdump -ni eth0 -p port 53 or port 853 and wait a minute!

 

[dave14305]

[QUOTE = "dave14305, publicación: 623365, miembro: 58901"]
El puerto 853 solo se verá en la interfaz WAN eth0. La interfaz LAN br0 seguirá mostrando solo el puerto 53.

DNSFilter debería estar interceptando el tráfico a OpenDNS. Confirme en la interfaz eth0 tcpdump.
[/CITAR]


there is no traffic on interface eth0


kabuto@RT-AC3200-D930:/tmp/home/root# tcpdump -i eth0 -p port 853 or 53 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes


^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Thank you

Try tcpdump -i vlan2 -p port 853 or 53 -n and if still no packets, show the results of tcpdump -D

 

[kabuto]

ok I see that the interface is vlan832 which is the one that my operator brings, in that if it goes out through port 853

Thanks for the help Mutzli and dave14305

 

[CaptnDanLKW]

Guys. In a few days I'm gonna fully reset my router. Since my usb that holds my amtm scripts etc just died (1 year sandisk ultra. The fit one. Not good since last week I saw using tune2fs that it's only been used at about 1TB) . I got a new sandisk max endurance 32gb for quite cheap and it should be able to hold of 100+ TBW afaik .

Now I'm on an AC86U and I've been keeping up to date with this thread and I know that jffs format and normal format is necessary to clean start it, but do I need to do the wps wipe thingy? Does it actually do anything different? Since I think I saw that wps wipe is kinda different in AC86U. Thanks !

I tried this a few weeks back. I have a 2x AIMesh RT-AC86U setup. I backed everything up; I'm familiar with this process, capable at the command line and know all about the hidden directories, manual & nuanced restore steps (like certs, dhcp, entware, rstats, etc... I had already done the /jffs backup, init and restore due to ASUS's 48MB->47MB resizing.

It did not go well - took way longer than expected and things never felt 'right'. Two show stoppers that caused my to revert and restore my backed up config&jffs.

First was that after a device reboot - which we do a lot of during reconfiguration - my WAN status would only connect 50% of the time. When it didn't work, the LED would remain RED and the WebUI would say disconnected. I have a STATIC IP address. If I toggled WAN disable -> enable that would NOT necessarily bring it back. If I toggled to DHCP and then back to static it would always work.

The straw that broke the proverbial camel's back is the inability to get the Traffic Analyzer (Not the AI Traffic Statistics) to work at all. There's another thread about this without a solution. The Process I use to enable and restore my traffic stats are: Set custom location, reset data files and then copy the old file back over. However, the problem is not the restore. Traffic Stats are always blank - it doesn't work. It does not collect and even when restoring the data, nothing is showed in the web interface when selecting a time period where there I know there is data.
There are 4 error messages echoed out to dmesg/syslog (didnt capture their exact names) when setting/changing the custom location and resetting the data files - something about about missing kernel modules. I suspect this is the reason, but why is a mystery since it working now, I'm running .19 and have not done a full reset since .13 (which the process worked).

I've done this rebuild dozens (hundreds?) of times over years with my RT-N66U, AT-AC68Us, etc.. without issue.

Set aside more time than you think you need.

I'm curious what your results are when you try. Post 'em up or DM me.

Though everything is running fine, I wanted to re-do because I have some major changes in the way I want syslog-ng to log. (scribe and scribeUI) I've hacked it together over the years but its time to clean it up and, apparently, there's a new syslog-ng.conf that looks nothing like the one I'm using, so I figured it was time.

 

[fg64]

Is the RT-AX88U having these troubles? I was considering that for my next upgrade, but that is downline several months. I'm just planning for now...

New AX88U running .19 out of the box for a month and an half with no issues. Been a great router so far.

 

[MaziahBebop]

Is the RT-AX88U having these troubles? I was considering that for my next upgrade, but that is downline several months. I'm just planning for now...

As per @fg64, 47 days uptime at this moment. Open VPN server and clients running all the time. Ram usage steady on 50%. Ax88u and .19 appear to be good together.

 

[AntonK]

Still smokin' along after 33 days. Actually, make that 45+ days as I suffered a power failure-caused reboot at about 12 days or so after upgrade.

 

[clayhans]

It never has if you want to see that information you need to go to QOS tab, then bandwith monitor and put on Apps analysis

Thanks for the info. I gave it a try and seems to work a bit.

 

[Thomas Szücs]

On my RT-AX88U I have noticed that it eats up around 100MB each day, so after 5 days I have to do a reset.
I run AMTM with Diversion. Any suggestions to what is so hungry?

 

[ColinTaylor]

On my RT-AX88U I have noticed that it eats up around 100MB each day, so after 5 days I have to do a reset.
I run AMTM with Diversion. Any suggestions to what is so hungry?

Why do you "have" to do a reset? What problem are you experiencing that forces you to do this?

 

[bbunge]

On my RT-AX88U I have noticed that it eats up around 100MB each day, so after 5 days I have to do a reset.
I run AMTM with Diversion. Any suggestions to what is so hungry?

Do you run Adaptive QOS? For some reason with fq_codel set on my AC86U the RAM usage would go up every day. A lot slower than 100MB per day.

 

[TonyK132]

I just updated to .19 but am having problems with the VPN client.

1. All clients are disabled, but in the logs, I'm still getting error messages about failure to connect to VPN. It seems that if the client is disabled, that the system should not try to connect or otherwise report any errors in the config (like for example, the CA cert is bad). BTW, this was also a problem in .18 and maybe also in earlier versions.
2. The TLS Renegotiation time has changed to a max value of 32767. I had mine set to 87300 since I only wanted it to renog every day at 24 hrs + 30 min which would cause a renog but only if my cru job did not run to renog daily at 3am. Now I no longer have that option. BTW, I have a script to do the renog at 3am because I run a streaming radio on my system during the day, and I found that a renog resets the VPN and stops the radio. My script causes a renog but only when I'm not using the system.

 

[TurboFreak68]

I went from version 384.16_0 to version 384.19_0 and it worked flawless couple of weeks and now suddenly last week it started to drop clients and they cant log back in instead gets denied (mobiles, Ipads, pc, apple tv and consoles). Someone else had this problem to and went back to version 384.18_0 and the problem seems to have stopped so something is strange in the code. I am super happy with the RT-AX88U overall before this software bug and have been great amd I have between 12-20 clients daily in my home network.

This is what i get from the log before the start to drop of,

Oct 9 16:38:04 hostapd: eth7: STA 3c:f0:11:da:0d:cc WPA: group key handshake completed (RSN)
Oct 9 16:38:04 hostapd: eth7: STA 18:ee:69:23:50:12 WPA: group key handshake completed (RSN)
Oct 9 16:38:04 hostapd: wl1.1: STA 54:a0:50:e3:0d:3c WPA: group key handshake completed (RSN)
Oct 9 16:38:05 hostapd: wl1.1: STA 2e:e6:5d:f0:4c:c2 WPA: group key handshake completed (RSN)
Oct 9 16:38:05 hostapd: eth7: STA e0:24:81:79:a8:3e WPA: group key handshake completed (RSN)
Oct 9 16:38:05 hostapd: eth7: STA c8:3c:85:23:d0:b5 WPA: group key handshake completed (RSN)
Oct 9 16:38:05 hostapd: eth7: STA a8:5b:78:06:7b:a5 WPA: group key handshake completed (RSN)
Oct 9 16:38:08 hostapd: eth6: STA ac:bc:32:76:bc:5e WPA: group key handshake failed (RSN) after 4 tries
Oct 9 16:38:08 hostapd: eth6: STA ba:c2:4f:4a:e5:09 WPA: group key handshake failed (RSN) after 4 tries
Oct 9 16:38:08 WLCEVENTD: Deauth_ind AC:BC:32:76:BC:5E
Oct 9 16:38:08 WLCEVENTD: Deauth_ind BA:C2:4F:4A:E5:09
Oct 9 16:38:08 hostapd: wl0.1: STA 34:a3:95:60:2e:9e WPA: group key handshake failed (RSN) after 4 tries
Oct 9 16:38:08 hostapd: wl0.2: STA 26:6a:8b:fe:d5:e4 WPA: group key handshake failed (RSN) after 4 tries
Oct 9 16:38:08 hostapd: wl0.2: STA 2e:bc:1d:40:d6:ce WPA: group key handshake failed (RSN) after 4 tries
Oct 9 16:38:08 WLCEVENTD: Deauth_ind 2E:BC:1D:406:CE
Oct 9 16:38:08 hostapd: wl0.2: STA d8:13:99:a6:58:73 WPA: group key handshake failed (RSN) after 4 tries

 

[ugandy]

I went from version 384.16_0 to version 384.19_0 and it worked flawless couple of weeks and now suddenly last week it started to drop clients and they cant log back in instead gets denied (mobiles, Ipads, pc, apple tv and consoles). Someone else had this problem to and went back to version 384.18_0 and the problem seems to have stopped so something is strange in the code. I am super happy with the RT-AX88U overall before this software bug and have been great amd I have between 12-20 clients daily in my home network.

This is what i get from the log before the start to drop of,

Oct 9 16:38:04 hostapd: eth7: STA 3c:f0:11:da:0d:cc WPA: group key handshake completed (RSN)
Oct 9 16:38:04 hostapd: eth7: STA 18:ee:69:23:50:12 WPA: group key handshake completed (RSN)
Oct 9 16:38:04 hostapd: wl1.1: STA 54:a0:50:e3:0d:3c WPA: group key handshake completed (RSN)
Oct 9 16:38:05 hostapd: wl1.1: STA 2e:e6:5d:f0:4c:c2 WPA: group key handshake completed (RSN)
Oct 9 16:38:05 hostapd: eth7: STA e0:24:81:79:a8:3e WPA: group key handshake completed (RSN)
Oct 9 16:38:05 hostapd: eth7: STA c8:3c:85:23:d0:b5 WPA: group key handshake completed (RSN)
Oct 9 16:38:05 hostapd: eth7: STA a8:5b:78:06:7b:a5 WPA: group key handshake completed (RSN)
Oct 9 16:38:08 hostapd: eth6: STA ac:bc:32:76:bc:5e WPA: group key handshake failed (RSN) after 4 tries
Oct 9 16:38:08 hostapd: eth6: STA ba:c2:4f:4a:e5:09 WPA: group key handshake failed (RSN) after 4 tries
Oct 9 16:38:08 WLCEVENTD: Deauth_ind AC:BC:32:76:BC:5E
Oct 9 16:38:08 WLCEVENTD: Deauth_ind BA:C2:4F:4A:E5:09
Oct 9 16:38:08 hostapd: wl0.1: STA 34:a3:95:60:2e:9e WPA: group key handshake failed (RSN) after 4 tries
Oct 9 16:38:08 hostapd: wl0.2: STA 26:6a:8b:fe:d5:e4 WPA: group key handshake failed (RSN) after 4 tries
Oct 9 16:38:08 hostapd: wl0.2: STA 2e:bc:1d:40:d6:ce WPA: group key handshake failed (RSN) after 4 tries
Oct 9 16:38:08 WLCEVENTD: Deauth_ind 2E:BC:1D:406:CE
Oct 9 16:38:08 hostapd: wl0.2: STA d8:13:99:a6:58:73 WPA: group key handshake failed (RSN) after 4 tries

i have the same problem. also ax88. started with 19b1 or 19b2 (not 100% sure but i think 19a1 was fine)
had to downgrade back to 18 because 2.4GHz was unusable
played with all the wireless settings (channel, options, etc) and nothing helped.
moved to 384.18 (with same amtm scripts) and wifi is rock solid.
couldn't pinpoint the culprit. log msgs similar (also had "local deauth request")
hoping 386.1 won't have same problem

 

[Jeffrey Young]

On my RT-AX88U I have noticed that it eats up around 100MB each day, so after 5 days I have to do a reset.
I run AMTM with Diversion. Any suggestions to what is so hungry?

Linux manages memory much different than Windows. Instead of letting unused memory sit around and do nothing, Linux will use it for cache and other things until it is needed by programs. At that time, Linux will give the memory back.

People fuss over Linux memory usage needlessly. If the router is working fine, don't bother resetting just because the memory "looks" like it is running low.