What's new

[Beta] Asuswrt-Merlin 384.6 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.
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.
 
Last edited:
RT-AC86U running fine (enabled the new DNS rebinding protection; DNSSEC was already on).
 
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 ...
 
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
 
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
 
Router: RT-AC88U
Firmware: Was: 384.5 , Now: 384.6_beta1

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

trend_micro_EULA_popup.jpg


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

administration_privacy_tab.jpg


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

Code:
...
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:

Code:
service restart_wireless

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

IDK?

.
 
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!
Code:
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?
 
Last edited:
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.
 
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.
 
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.
 
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.
 
@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.
 
Last edited:
@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.
 
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.
 
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:

Code:
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.
 
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top