[Beta] Asuswrt-Merlin 384.6 beta is now available

[Howard_inGA]

RT-AC5300-Dirty Upgrade
I use IPv6. Had to power cycle (with a 4 minute pause) the Comcast cable modem. I went ahead and power cycled the router and the hardwired computer. All is well and running fine now...
Also had to reset the Traffic Monitoring data files on the attached thumb drive.

 

[XIII]

RT-AC86U running fine (enabled the new DNS rebinding protection; DNSSEC was already on).

 

[JIPG]

I see 3.0.0.4.382.50702 has been released today (18 July) by ASUS for the AC87U, no source code yet.

These are really good news!. It was a nonsense that a really good router was kept without updates. ..
I expect the GPL code is released soon ...

 

[Marin]

I wouldn't recommend updating via wireless. Too many issues can occur, which are easily avoidable via a wired connection.

Yes I couldn’t agree more!


Sent from my iPhone using Tapatalk

 

[eddiez]

I wouldn't recommend updating via wireless. Too many issues can occur, which are easily avoidable via a wired connection.

True...But I've been updating my firmware for the past 3 years wirelessly. Every alfa, beta and final version...No issues ever.

 

[daviworld]

True...But I've updating my firmware for the past 3 years wirelessly. Every alfa, beta and final version...No issues ever.

I use to be that way originally, now I reverted to updating firmware via Ethernet. I can agree with Marin on the wireless issue. While most of the time the update went smooth, every now and then over wireless, the firmware update process would never move past "applying updates, please wait..." But never went to the progress bar, and required rebooting the router

One day experimenting with this issue, I decided to wait 20mins, still said "applying updates, please wait..." And rebooted to see if the router would brick or become corrupt. To my surprise it did update the firmware, the UI for the firmware however never changed or indicated installation.

On wired the only weirdness I experienced is Firefox lags way behind on the router progress bar. Such as the update could be finished, but Firefox will still be at like 60% until you refresh. Chrome so far doesn't lag like Firefox.

Anyways, just wanted to throw in my 2 cent on why I agreed with firmware upgrades over wired

Sent from my LG-H830 using Tapatalk

 

[martywd]

Router: RT-AC88U
Firmware: Was: 384.5 , Now: 384.6_beta1

Upload and reboot went ok. But once logged in, I get this popup:

Also I now see a new tab in 'Administration' labelled 'Privacy':

I have been using 'Adaptive QOS' w/ the 'FreshJR_QOS' and 'FreshJR_QOS_fakeTC' scripts for a while now in 384.x firmware, but I've never had to 'Agree' to this EULA before in order to use QOS. And clicking 'Disagree' disables QOS. Is this expected behavior now, i.e., 'Agree' to Trend Micro's EULA, or Adaptive QOS will not work?

Other than this EULA issue, and the fact that QOS was not working, all was well for the next 12+ hours.

Then I rebooted.

Another issue, after just described boot up. Looking at the 'System Log-General log' I see a flood of the following which I was not seeing after the initial update to '384.6_beta1'.

...
Jul 19 13:01:44 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:46 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:47 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:52 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:53 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:53 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:53 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:53 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:54 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:55 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:55 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:56 kernel: TCP: time wait bucket table overflow
Jul 19 13:01:57 kernel: TCP: time wait bucket table overflow
...

Looked around the forums a bit, these messages seemed wireless related?

So ssh'd into the router restarted the wireless:

service restart_wireless

Since issuing that command, no more 'TCP: time wait bucket table overflow' messages.

IDK?

.

 

[InstantAli3n]

Anything I can do to fix this? There's about 200 lines of this going up untill post time:
I want to say this started with the first alpha for 384.6, it could have been the second one though. (Cloudflare isn't letting me post this without putting a space after /etc/.)
Sorry!

Spoiler: Nevermind! I changed my adapter's mac address.

Jul 18 03:24:33 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 03:41:40 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 03:41:42 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 03:51:31 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 04:24:36 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 04:24:37 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 04:42:42 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 04:42:43 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 04:48:50 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 04:53:51 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 04:58:50 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 05:52:52 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 05:52:56 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 05:55:55 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 05:56:46 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 05:56:47 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 05:59:48 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 06:01:58 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 06:03:55 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 06:04:47 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 06:06:50 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 06:11:55 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 06:12:26 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 06:12:30 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 06:13:57 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 07:17:16 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 07:28:10 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 09:58:36 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115
Jul 18 10:39:34 dnsmasq-dhcp[324]: not giving name DESKTOP-INSTANT to the DHCP lease of 192.168.1.64 because the name exists in /etc/ hosts.dnsmasq with address 192.168.1.115

Also, does anyone know these DNS servers support DNSSEC? 8.8.4.4 and 4.2.2.2 I don't know how to check.

Would the new "dnsmasq[323]: Insecure DS reply received, do upstream DNS servers support DNSSEC?" notification happen either way if I have "Advertise router's IP in addition to user-specified DNS" enabled?

 

[Nigel Jones]

True...But I've updating my firmware for the past 3 years wirelessly. Every alfa, beta and final version...No issues ever.

Same here


Sent from my iPhone using Tapatalk

 

[RMerlin]

Is this expected behavior now

Adaptive QoS has always used the Trend Micro DPI engine, and therefore was subject to their EULA. The only change is that the EULA is shown again with updated language on first time you log in following the update, with the new added option of opting out of an already accepted EULA.

This change comes from upstream, not from me.

 

[RMerlin]

Folks, if you have question about DNSSEC and which server supports it, please do so in a separate thread. This has nothing to do with this beta release, as DNSSEC is in no way a new feature.

 

[MarkRH]

This firmware is working fine on my RT-AC68U. Like with the alphas, I see no funky 4Gig upload spikes with every 4Gig of download. Between you and Asus that seems to be fixed from 384.5. Thanks for your efforts.

 

[martywd]

Adaptive QoS has always used the Trend Micro DPI engine, and therefore was subject to their EULA. The only change is that the EULA is shown again with updated language on first time you log in following the update, with the new added option of opting out of an already accepted EULA.

This change comes from upstream, not from me.

I swears, I've never encountered the TM EULA before, thus my surprise (and confusion) at it's appearence in this RT-AC88U_384.6_beta1. Thank you for the clarification.

 

[HowIFix]

@RMerlin
You need test with DNScrypt v2 with CloudFLARE DNS 1.1.1.1 (DoH), Enable DNSSEC (LAN -> DHCP Server) and CloudFLARE DNS 1.1.1.1/1.0.0.1 in WAN.

 

[RMerlin]

@RMerlin
You need test with DNScrypt v2 with CloudFLARE DNS 1.1.1.1 (DoH), Enable DNSSEC (LAN -> DHCP Server) and CloudFLARE in WAN.

I don't support nor use DNSCRYPT.

 

[HowIFix]

I don't support nor use DNSCRYPT.

But only this error occurs in this version (384.6 beta 1) in the version 384.5 works without problems.

 

[RMerlin]

Reviewing the results, I'm not 100% sure about the DNSSEC test result from my ISP's servers. I'll have to re-test with different servers, but I can't do so right now.

 

[Striker317]

But only this error occurs in this version (384.6 beta 1) in the version 384.5 works without problems.

Does it also happen in the stock Asus firmware?

 

[RMerlin]

Re-tested properly with my ISP's nameservers (first test was invalid because Ubuntu was using its own dnsmasq instead of the router). Once I force the query through my router, it confirms that DNSSEC is working properly for me when using my ISP's DNS:

merlin@ubuntu-dev:~$ dig asuswrt.lostrealm.ca @192.168.10.1
; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> asuswrt.lostrealm.ca @192.168.10.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35847
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;asuswrt.lostrealm.ca.        IN    A
;; ANSWER SECTION:
asuswrt.lostrealm.ca.    300    IN    A    72.55.186.51
;; Query time: 109 msec
;; SERVER: 192.168.10.1#53(192.168.10.1)
;; WHEN: Thu Jul 19 23:22:56 EDT 2018
;; MSG SIZE  rcvd: 65

The ad flag in the response confirms that the query was authenticated by DNSSEC. Therefore I have working DNSSEC validation on my LAN without any error message in my log. Makes me suspect that Cloudflare is the one that's broken, might be possibly due to their lack of proper support for EDNS. Dnsmasq DNSSEC validation is stricter than previous versions, so broken upstream servers might no longer work as before. You can work around this by disabling strict mode through dnsmasq.conf.add, however you will be giving up a portion of the added security DNSSEC is intended to provide you.

So if you want REALLY working DNSSEC support, you need to use an upstream nameserver that properly supports it. Cloudflare does not.

 

[HowIFix]

Does it also happen in the stock Asus firmware?

Stock firmware does not have this option and does not support any script, the only reason to use stock firmware is by AiMesh and not even AiMesh works well.

Asuswrt-Merlin > stock firmware