What's new

[Release] Asuswrt-Merlin 384.13 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.
Had an interesting thing happen with my OVPN client settings. I realized today that OVPN Client #1 on my local router wasn't connected to the OVPN server on my remote (ASUS) router. The remote router is on a relatively unstable internet connection, and occasionally the internet connection goes down, causing the OVPN link to go down. I tried restarting the OVPN connection as usual, but it wouldn't go this time. As I was reviewing the OVPN client connection settings, I found that some garbage characters had been added to the last line of my Custom Configuration entries. Once I removed the garbage characters, I was able to successfully start the OVPN session. This was for an OVPN client on an AC86U connecting to an OVPN server on another AC86U. Both running 384.13. No idea how the garbage characters got there. I upgraded to 384.13 whenever it came out (a month ago?), and haven't made any changes to the router config since then.
 
Hi,

I got last week or so a RT-AX88U router and have also a RT-AC68U router as a aimesh(connected with ethernet)
I have noticed some "connection?" dropouts both with streaming and also when copying files in my network. It doesn't matter if I use wifi or ethernet.
What I did, was installed instantly merlins firmware and reseted the router and just manually put it all configuration then I reseted my RT-AC68U also and added it as aimesh node. Both are on the latest 384.13 firmware.

I get alot of these "kernel: net_ratelimit: xxxx callbacks suppressed". Not sure if they are releated or not

Sep 9 04:29:56 dnsmasq-dhcp[9422]: DHCPREQUEST(br0) 192.168.1.118 xx:xx:xx:xx:xx:xx
Sep 9 04:29:56 dnsmasq-dhcp[9422]: DHCPACK(br0) 192.168.1.118 xx:xx:xx:xx:xx:xx
Sep 9 04:50:11 dnsmasq-dhcp[9422]: DHCPREQUEST(br0) 192.168.1.170 xx:xx:xx:xx:xx:xx
Sep 9 04:50:11 dnsmasq-dhcp[9422]: DHCPACK(br0) 192.168.1.170 xx:xx:xx:xx:xx:xx
Sep 9 04:55:53 kernel: net_ratelimit: 1629 callbacks suppressed
Sep 9 04:59:09 kernel: net_ratelimit: 756 callbacks suppressed
Sep 9 04:59:09 WLCEVENTD: ReAssoc xx:xx:xx:xx:xx:xx
Sep 9 05:15:53 kernel: net_ratelimit: 1145 callbacks suppressed
Sep 9 05:35:53 kernel: net_ratelimit: 4996 callbacks suppressed
Sep 9 05:35:54 dnsmasq-dhcp[9422]: DHCPREQUEST(br0) 192.168.1.205 xx:xx:xx:xx:xx:xx
Sep 9 05:35:54 dnsmasq-dhcp[9422]: DHCPACK(br0) 192.168.1.205 xx:xx:xx:xx:xx:xx
Sep 9 05:45:53 kernel: net_ratelimit: 9860 callbacks suppressed

I have tried to turn off all extra...but I have dhcp server on with mac bidings

Another thing perhaps relatead...
Why some devices are connected twice or are they?

upload_2019-9-9_8-38-1.png
 
Hi, I have been using Merlin firmware for very long times since RT-Nxx series. I am really appreciated for your hard work. Currently, I am using RT-AX88U as a main router and connected with 2 x RT-AC68U ( original not converted ) as an AP and RT-AC66U as switch. I have and issue with 384.13 that I can't stream 4K High Bitrate ( 50-90Gb / files ) on Kodi via internet my internet speed is 1Gbps. It always stuck and buffer couldn't stream. But 4K not high bitrate ( 30Gb and lower / files ) and lower resolution like FullHD or HD that is fine. I didn't noticed that because of the 384.13 firmware. I thought it was my internet issue. Then I reverted back to 384.12 everything went back to normal. I was not so sure that because of the firmware related. I did flash to 384.13 again and the issue come back. So, I am sure that in my network system if I use 384.13 firmware I will have an issue when streaming high bitrate. Anyone facing this issue too?

PS. I didn't use any VPN also QOS. Streaming Netflix and Amazon Video highest format without problem. I guess the bitrate weren't that high.
 
Last edited:
Hi,

I got last week or so a RT-AX88U router and have also a RT-AC68U router as a aimesh(connected with ethernet)
I have noticed some "connection?" dropouts both with streaming and also when copying files in my network. It doesn't matter if I use wifi or ethernet.
What I did, was installed instantly merlins firmware and reseted the router and just manually put it all configuration then I reseted my RT-AC68U also and added it as aimesh node. Both are on the latest 384.13 firmware.

I get alot of these "kernel: net_ratelimit: xxxx callbacks suppressed". Not sure if they are releated or not

Sep 9 04:29:56 dnsmasq-dhcp[9422]: DHCPREQUEST(br0) 192.168.1.118 xx:xx:xx:xx:xx:xx
Sep 9 04:29:56 dnsmasq-dhcp[9422]: DHCPACK(br0) 192.168.1.118 xx:xx:xx:xx:xx:xx
Sep 9 04:50:11 dnsmasq-dhcp[9422]: DHCPREQUEST(br0) 192.168.1.170 xx:xx:xx:xx:xx:xx
Sep 9 04:50:11 dnsmasq-dhcp[9422]: DHCPACK(br0) 192.168.1.170 xx:xx:xx:xx:xx:xx
Sep 9 04:55:53 kernel: net_ratelimit: 1629 callbacks suppressed
Sep 9 04:59:09 kernel: net_ratelimit: 756 callbacks suppressed
Sep 9 04:59:09 WLCEVENTD: ReAssoc xx:xx:xx:xx:xx:xx
Sep 9 05:15:53 kernel: net_ratelimit: 1145 callbacks suppressed
Sep 9 05:35:53 kernel: net_ratelimit: 4996 callbacks suppressed
Sep 9 05:35:54 dnsmasq-dhcp[9422]: DHCPREQUEST(br0) 192.168.1.205 xx:xx:xx:xx:xx:xx
Sep 9 05:35:54 dnsmasq-dhcp[9422]: DHCPACK(br0) 192.168.1.205 xx:xx:xx:xx:xx:xx
Sep 9 05:45:53 kernel: net_ratelimit: 9860 callbacks suppressed

I have tried to turn off all extra...but I have dhcp server on with mac bidings

Another thing perhaps relatead...
Why some devices are connected twice or are they?

View attachment 19290

Smart connect on my Note 9 connects to my Samsung 55 TV running TIZEN, so it appears on my AC86U as 2 devices connecting to it.
 
My AC86U gui locked up (couldn't access via web interface, had to reboot). Will this be fixed on next firmware release, @RMerlin ? I saw that this bug was fixed on the ASUS firmware
 
If you can't access the WebGUI of your device, enter the following command via CLI/Command-line Interface. The only caveat is that you have to have ssh enabled.

# service restart_httpd
 
If you can't access the WebGUI of your device, enter the following command via CLI/Command-line Interface. The only caveat is that you have to have ssh enabled.

# service restart_httpd
right..my point was is that this is a bug as the GUI shouldnt do this period.
 
This is great info. Many thanks. I will try it whenever / if the problem reproduces and post back.

Well, it happened again. 5Ghz hunged and fails to authenticate, but restarting eapd either does not fix the problem. Any other idea ?
 
Well, it happened again. 5Ghz hunged and fails to authenticate, but restarting eapd either does not fix the problem. Any other idea ?

Are you using any Trend Micro features? Have you tried running without them... Administration\Privacy\Withdraw? I had one instance of failure to authenticate 5.0 clients (get IP address) and noticed abnormal memory usage. I disabled TM and have not seen this again. This was on an 86U running stock firmware 45717, same as in Merlin 384.13.

OE
 
Are you using any Trend Micro features? Have you tried running without them... Administration\Privacy\Withdraw? I had one instance of failure to authenticate 5.0 clients (get IP address) and noticed abnormal memory usage. I disabled TM and have not seen this again. This was on an 86U running stock firmware 45717, same as in Merlin 384.13.

OE

Thanks for the Idea. I tried disabling trendmicro stuff and restarting the wireless service, to no avail. Then tried changing several wireless parameters (universal roaming / fairness /.. ) but still nothing. At certain point I could connect but the 5GHz band was serving at a very-very slow pace. It looks like it is so slow that only 1 in every 10-20 connection attempts does succeed and traffic flows but also very slow afterwards.
Well, I may leave it as it is for the night and will keep on testing tomorrow.
 
Strange, last month after installing the new firmware I had the DNSEC validation test showing me that most of the DS algorithms are verified in green:
upload_2019-9-10_10-41-34.png


A quick check this morning showed me that it doesn't do that any longer. Here is the latest rootcanary test:
upload_2019-9-10_10-42-57.png


I haven't changed any settings since the first image and second image in the firmware. The reason I checked this morning was to test the new Firefox extension 'Firefox Private Network' that disguises your IP address by sending all traffic through a proxy service provided by Cloudflare (https://private-network.firefox.com/welcome). But that's no the reason for the DNSEC validations to fail on some algorithm since the choice of browser doesn't matter. Does anyone have an explanation of what changed in the last 40 days?
 

Attachments

  • upload_2019-9-10_10-48-56.png
    upload_2019-9-10_10-48-56.png
    200.2 KB · Views: 261
Strange, last month after installing the new firmware I had the DNSEC validation test showing me that most of the DS algorithms are verified in green:
View attachment 19297

A quick check this morning showed me that it doesn't do that any longer. Here is the latest rootcanary test:
View attachment 19298

I haven't changed any settings since the first image and second image in the firmware. The reason I checked this morning was to test the new Firefox extension 'Firefox Private Network' that disguises your IP address by sending all traffic through a proxy service provided by Cloudflare (https://private-network.firefox.com/welcome). But that's no the reason for the DNSEC validations to fail on some algorithm since the choice of browser doesn't matter. Does anyone have an explanation of what changed in the last 40 days?
Is it ok if you use another browser? Seems to me that routing all browser traffic through this service is the smoking gun here.
 
Strange, last month after installing the new firmware I had the DNSEC validation test showing me that most of the DS algorithms are verified in green:
View attachment 19297

A quick check this morning showed me that it doesn't do that any longer. Here is the latest rootcanary test:
View attachment 19298

I haven't changed any settings since the first image and second image in the firmware. The reason I checked this morning was to test the new Firefox extension 'Firefox Private Network' that disguises your IP address by sending all traffic through a proxy service provided by Cloudflare (https://private-network.firefox.com/welcome). But that's no the reason for the DNSEC validations to fail on some algorithm since the choice of browser doesn't matter. Does anyone have an explanation of what changed in the last 40 days?
Doesn't Firefox's service you are using use DoH so you are not seeing things correctly?
 
Is it ok if you use another browser? Seems to me that routing all browser traffic through this service is the smoking gun here.
No, doesn't help. It's the same on Edge or Chrome.
 
Doesn't Firefox's service you are using use DoH so you are not seeing things correctly?
I have DoH turned off in Firefox 69.0. It's not on by default yet, it will be a default setting in Firefox 70.
 
Could be a change with your upstream providers.

That test is misleading because it doesn't specifically report what YOUR resolver (i.e. your router) supports.
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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