Release [Beta] Asuswrt-Merlin 384.19 beta is now available

[mandepsi]

@ RMerlin
Both v. 384.18 and v, 384.19_Beta are ignoring unchecked 160 MHz option in repeater modus and connecting with 160 MHz. Some would ask what is the problem? The problem is low RSSI also low throughput in to USBHDD with 160 MHz. v. 384.17 in with 80Mhz my throughput is 36 Mbps( Band: 5GHz, Link rate: 866.5 Mbps, RSSI: -44 dBm) but with 160 MHz (Band: 5GHz Link rate: 1729 Mbps RSSI: -67 dBm) only 17 Mbps.
My Device is RT-AC88U
Can you please check it?

 

[brummygit]

the modem is set to DHCP. no authentication scheme or other things. IPv4

OK do you also use Adaptive QoS?

 

[Triton]

OK do you also use Adaptive QoS?

No. only thing i don't mention in my signature is AIprotect

 

[ugandy]

No. only thing i don't mention in my signature is AIprotect

during the periods that you don't get "WAN_Connection: Ethernet link down" do you have packet loss (ping 8.8.8.8) ? i had a bad comcast cable line, that caused lot of packet loss, which then translated to frequent WAN disconnects. once the line was fixed, WAN disconnect were gone.

 

[nzwayne]

i did. nothing changed, cat6 cable and the ISP checked the modem, no issues there. same cable that was used before. Modem is an Arris TM3402B

Had this symptom about 3-4mths ago. Everything checked out ok, changed ethernet cable, Arris 3452a modem tested ok with the ISP. Then Arris modem died a few days later (naughty words said...). No more issues after replacement modem. Have a plan-B ready for internet, should events unravel occur like mine.

 

[Triton]

during the periods that you don't get "WAN_Connection: Ethernet link down" do you have packet loss (ping 8.8.8.8) ? i had a bad comcast cable line, that caused lot of packet loss, which then translated to frequent WAN disconnects. once the line was fixed, WAN disconnect were gone.

no packet loss in the logs. i use 1.1.1.1 and 9.9.9.9 as secondary.
the modem is only some months old. the issue appeared after the update. weird coincidence if the is the issue.

 

[ugandy]

no packet loss in the logs. i use 1.1.1.1 and 9.9.9.9 as secondary.
the modem is only some months old. the issue appeared after the update. weird coincidence if the is the issue.

you can always go back and see if problem goes away

 

[Triton]

you can always go back and see if problem goes away

sure. but i just report issues that came up with the beta, as we are supposed to
if they are related is up to Merlin to decide

 

[Mark Taylor]

sure. but i just report issues that came up with the beta, as we are supposed to
if they are related is up to Merlin to decide

I have the Ax88U and mine works fine with 384.19B1. I did note though that Asus have released very quickly a new firmware to address by the looks some connection issues as below. It might be relevant to the type of connection you have. I have PPPoE 1000/50 fibre and dynamic IP.
ASUS RT-AX88U Firmware version 3.0.0.4.384.9566
- Fixed static IP WAN connection issues.
- Fixed wan link aggregation stability issues.

 

[SomeWhereOverTheRainBow]

I cannot access the webui after updating to .19 Beta 1 on my RTAX88U from version .18. webui hangs. I have tried restarting httpd numerous times. still same issue. same issue persist after reboots as well.

 

[JohnSmith]

I cannot access the webui after updating to .19 Beta 1 on my RTAX88U from version .18. webui hangs. I have tried restarting httpd numerous times. still same issue. same issue persist after reboots as well.

See my post https://www.snbforums.com/threads/beta-asuswrt-merlin-384-19-beta-is-now-available.65581/post-608402 and see if this affects you

 

[RMerlin]

This is the output when using a subnet:
xxxx@RT-AX88U-F5E0:/tmp/home/root# cat /etc/openvpn/client1/dns.sh
#!/bin/sh
/usr/sbin/iptables -t nat -N DNSVPN1
/usr/sbin/iptables -t nat -I PREROUTING -p udp -m udp --dport 53 -j DNSVPN1
/usr/sbin/iptables -t nat -I PREROUTING -p tcp -m tcp --dport 53 -j DNSVPN1



This is the output when using a single IP-address:
xxxx@RT-AX88U-F5E0:/tmp/home/root# cat /etc/openvpn/client1/dns.sh
#!/bin/sh
/usr/sbin/iptables -t nat -N DNSVPN1
/usr/sbin/iptables -t nat -A DNSVPN1 -s 172.16.1.11 -j DNAT --to-destination 10.70.0.1
/usr/sbin/iptables -t nat -I PREROUTING -p udp -m udp --dport 53 -j DNSVPN1
/usr/sbin/iptables -t nat -I PREROUTING -p tcp -m tcp --dport 53 -j DNSVPN1

Source validation was failing when a CIDR was used instead of just an IP address. Fixed with this commit.

 

[RMerlin]

1. Network Map Clients List still changes dynamically on its own, which in turn dynamically changes clients shown on Adaptive QOS | Bandwidth Monitor

2. Under Guest Network | 2.4GHZ | 2nd Network setup for IOT devices, which they used to show up under Adaptive QOS | Bandwidth Monitor, but now none of them are showing up, yet they show up under connected devices under System Log | Wireless Log as before.

Anything related to Networkmap, Wifi, Adaptive QoS, Traffic Analyzer, etc... is closed source, and outside of my control. Any issue will have to be resolved by Asus.

@ RMerlin
Both v. 384.18 and v, 384.19_Beta are ignoring unchecked 160 MHz option in repeater modus and connecting with 160 MHz. Some would ask what is the problem? The problem is low RSSI also low throughput in to USBHDD with 160 MHz. v. 384.17 in with 80Mhz my throughput is 36 Mbps( Band: 5GHz, Link rate: 866.5 Mbps, RSSI: -44 dBm) but with 160 MHz (Band: 5GHz Link rate: 1729 Mbps RSSI: -67 dBm) only 17 Mbps.
My Device is RT-AC88U
Can you please check it?

The RT-AC88U does not support 160 MHz.

 

[SomeWhereOverTheRainBow]

Okay so on my RT-AX88U, I experienced nt_center.db, where this file grew so large it over filled my JFFS. ---> my solution was that i restored JFFS from backup.tar , but before i did so I deleted the nt_center.db file inside the backup.tar. Before i did this, I formatted JFFS completely. Ultimately this resolved the cannot delete from jffs issue that having a full jffs creates, while making sure this file was not out of control.

 

[FLA_NL]

I went back to 384.18 again. Still have WAN connection issues with 38.19_beta1. There is a severe chance that the WAN connection doesn't come up after reboot. To get internet/wan working again with 384.19_beta1, I had to reboot again or flip the Internet Connection toggle on the Internet status section in the router GUI. Don't have this issue with older firmware releases. I switched back to 384.18, because if there are some network issues, and I'm not at home the router can be restarted to get things working again. (RT-AC86U, DoT, OpenVPN client/server, NTP server, DNS filter, double NAT, DDNS)

 

[Intrepid2007]

Source validation was failing when a CIDR was used instead of just an IP address. Fixed with this commit.

Great, thanks

 

[ViRUS2k]

if you have QoS or AiProtection enabled, that would be one possible reason

nice catch AI protection was enabled for some reason im sure i disabled it but it hmm anyway fixed

 

[brummygit]

No. only thing i don't mention in my signature is AIprotect

OK there was an issue reported and documented in the Wiki if you use DHCP to get your IP address from the modem, Asus adaptive QoS blocks the lease renewal confirmations resulting in a disconnect when the lease expires - but sounds like not your problem.

no packet loss in the logs. i use 1.1.1.1 and 9.9.9.9 as secondary.
the modem is only some months old. the issue appeared after the update. weird coincidence if the is the issue.

I was using 1.1.1.1 for WAN detection on my Dual WAN setup recently and Cloudflare started having issues (probably a couple of weeks ago) meaning I kept failing over to 4G. I switched to 8.8.8.8 instead and all has been fine.

I have found that my secondary WAN connection uses Automatic IP (DHCP) but doesn't detect properly unless I use manual DNS server settings (Connect to DNS Server automatically = No) for that connection.

I have the Ax88U and mine works fine with 384.19B1. I did note though that Asus have released very quickly a new firmware to address by the looks some connection issues as below. It might be relevant to the type of connection you have. I have PPPoE 1000/50 fibre and dynamic IP.
ASUS RT-AX88U Firmware version 3.0.0.4.384.9566
- Fixed static IP WAN connection issues.
- Fixed wan link aggregation stability issues.

Saw this too and think it's the reason I MUST use Automatic IP (DHCP) for my secondary WAN. Will test in a future Merlin release that includes this GPL

I went back to 384.18 again. Still have WAN connection issues with 38.19_beta1. There is a severe chance that the WAN connection doesn't come up after reboot. To get internet/wan working again with 384.19_beta1, I had to reboot again or flip the Internet Connection toggle on the Internet status section in the router GUI. Don't have this issue with older firmware releases. I switched back to 384.18, because if there are some network issues, and I'm not at home the router can be restarted to get things working again. (RT-AC86U, DoT, OpenVPN client/server, NTP server, DNS filter, double NAT, DDNS)

See above - the Asus code this release is based on seems to have issues with Static IP on the WAN and also DHCP on the WAN. Maybe something above will help - I've spent ages trying to fix my Dual WAN and now seem to have it working.

 

[ViRUS2k]

Probably already been answered but how in gods green earth can i get rid of these in my history log

---

8 00:15:59 kernel: DROP IN=ppp0 OUT= MAC= SRC=37.49.225.166 DST=51.148.166.159 LEN=49 TOS=0x00 PREC=0x00 TTL=246 ID=54321 PROTO=UDP SPT=60408 DPT=5683 LEN=29
Aug 8 00:16:01 kernel: DROP IN=ppp0 OUT= MAC= SRC=45.129.33.40 DST=51.148.166.159 LEN=40 TOS=0x00 PREC=0x00 TTL=248 ID=2170 PROTO=TCP SPT=58618 DPT=30916 SEQ=1319360033 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
Aug 8 00:16:20 kernel: DROP IN=ppp0 OUT= MAC= SRC=125.64.94.130 DST=51.148.166.159 LEN=40 TOS=0x00 PREC=0x00 TTL=242 ID=54321 PROTO=TCP SPT=35807 DPT=110 SEQ=1769365306 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0
Aug 8 00:16:31 kernel: DROP IN=ppp0 OUT= MAC= SRC=193.32.161.149 DST=51.148.166.159 LEN=40 TOS=0x00 PREC=0x00 TTL=249 ID=45133 PROTO=TCP SPT=51261 DPT=65508 SEQ=2599151926 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
Aug 8 00:16:32 kernel: DROP IN=ppp0 OUT= MAC= SRC=81.98.81.101 DST=51.148.166.159 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=45899 DF PROTO=TCP SPT=23061 DPT=7680 SEQ=3058404864 ACK=0 WINDOW=65472 RES=0x00 SYN URGP=0 OPT (0204055401010402)
Aug 8 00:16:33 kernel: DROP IN=ppp0 OUT= MAC= SRC=81.98.81.101 DST=51.148.166.159 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=45900 DF PROTO=TCP SPT=23061 DPT=7680 SEQ=3058404864 ACK=0 WINDOW=65472 RES=0x00 SYN URGP=0 OPT (0204055401010402)
Aug 8 00:16:35 kernel: DROP IN=ppp0 OUT= MAC= SRC=81.98.81.101 DST=51.148.166.159 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=45901 DF PROTO=TCP SPT=23061 DPT=7680 SEQ=3058404864 ACK=0 WINDOW=65472 RES=0x00 SYN URGP=0 OPT (0204055401010402)
Aug 8 00:16:39 kernel: DROP IN=ppp0 OUT= MAC= SRC=81.98.81.101 DST=51.148.166.159 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=45902 DF PROTO=TCP SPT=23061 DPT=7680 SEQ=3058404864 ACK=0 WINDOW=65472 RES=0x00 SYN URGP=0 OPT (0204055401010402)
Aug 8 00:16:44 kernel: DROP IN=ppp0 OUT= MAC= SRC=45.129.33.24 DST=51.148.166.159 LEN=40 TOS=0x00 PREC=0x00 TTL=249 ID=52140 PROTO=TCP SPT=56008 DPT=21828 SEQ=3985651831 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
Aug 8 00:16:47 kernel: DROP IN=ppp0 OUT= MAC= SRC=81.98.81.101 DST=51.148.166.159 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=45903 DF PROTO=TCP SPT=23061 DPT=7680 SEQ=3058404864 ACK=0 WINDOW=65472 RES=0x00 SYN URGP=0 OPT (0204055401010402)
Aug 8 00:16:56 kernel: DROP IN=ppp0 OUT= MAC= SRC=195.54.160.53 DST=51.148.166.159 LEN=40 TOS=0x00 PREC=0x00 TTL=249 ID=44560 PROTO=TCP SPT=57467 DPT=45007 SEQ=2620303168 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
Aug 8 00:17:00 kernel: DROP IN=ppp0 OUT= MAC= SRC=125.212.217.214 DST=51.148.166.159 LEN=44 TOS=0x00 PREC=0x00 TTL=110 ID=16979 PROTO=TCP SPT=13944 DPT=1010 SEQ=239357119 ACK=0 WINDOW=22760 RES=0x00 SYN URGP=0 OPT (020405B4)
Aug 8 00:17:45 kernel: DROP IN=ppp0 OUT= MAC= SRC=195.54.160.53 DST=51.148.166.159 LEN=40 TOS=0x00 PREC=0x00 TTL=249 ID=24160 PROTO=TCP SPT=57467 DPT=6622 SEQ=2125783329 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0

-----------------------

I have about a billion of them.... :/

 

[octopus]

Just turn off logging. Should solve your problem.