[Release] Asuswrt-Merlin 380.64_2 is now available

[Makaveli]

Yah I am think Bandwidth Limiter might be Reversing UP/DOWN which would explain why some client I set to 3D/1.5U were doing 1.5D/3U

Wired Connections seem to respect it I will check Wifi for 2g and 5g Tommorow.

Isn't this a known asus bug for awhile now?

 

[tsunami2311]

shrugs dont know, I only in last month or 2 started using bandwidth limiter over traditional and before that I was using traditional QOS that I set it to 100down-35up it limited speeds to those settings correctly. Unless I specified a wired client to have more then 100down/35up in which case it would go faster but the router cpu limits speeds to around 100-110 down or up with traditional QOS.

With bandwidth limiting those same wired clients can hit 120-130 down but as far as I can tell wired clients respect the limiting rules. I will report back tomorrow when I can check the 2g/5g clients.

 

[ech]

I wonder whether others have noticed/seen this behavior, and I'm not entirely sure it will reproduce, but... I had a VPN client running for a while, not having any issues for a week, and then I noticed every 2 hours (+ a minute or two) I'd get this logged:

Dec 27 17:16:49 openvpn[11452]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 27 17:16:49 openvpn[11452]: TLS Error: TLS handshake failed

and around that time, attempts to use the VPN would be hung (as expected) and would come back to life on their own a bit later, only to be interrupted again a couple hours further down the road. Restarting the VPN client didn't solve the problem, as the errors came back, over and over, every two hours. Rebooting the router did clear the problem and the VPN has been solid for over a day. Now to wait and see if the problem comes back again 7 days later.

Any other debug info I should collect before/after (assuming it happens again) that would help track down the cause of the problem?

Thanks,
-Eric

 

[Xentrk]

I wonder whether others have noticed/seen this behavior, and I'm not entirely sure it will reproduce, but... I had a VPN client running for a while, not having any issues for a week, and then I noticed every 2 hours (+ a minute or two) I'd get this logged:

Dec 27 17:16:49 openvpn[11452]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 27 17:16:49 openvpn[11452]: TLS Error: TLS handshake failed

and around that time, attempts to use the VPN would be hung (as expected) and would come back to life on their own a bit later, only to be interrupted again a couple hours further down the road. Restarting the VPN client didn't solve the problem, as the errors came back, over and over, every two hours. Rebooting the router did clear the problem and the VPN has been solid for over a day. Now to wait and see if the problem comes back again 7 days later.

Any other debug info I should collect before/after (assuming it happens again) that would help track down the cause of the problem?

Thanks,
-Eric

Hi Eric,

What values do you have in these fields? These are mine.

"reneg-sec" is the same thing as what is configured under "TLS Renegotiation Time" on the webui. You should remove that line, and change that setting from -1 to 0 instead.

https://openvpn.net/index.php/open-...-seconds-check-your-network-connectivity.html

Also, describe your physical layer. For example, is your device connencted to another router? Modem?

 

[ech]

Hi Eric,

What values do you have in these fields? These are mine.

View attachment 8088



https://openvpn.net/index.php/open-...-seconds-check-your-network-connectivity.html

I have "-1" and "30" set in those fields... but setting that to "0" and "-1"... wouldn't that effectively mask problems? And why would I have no problems at all for a week and just start having periodic every 2 hours issues then, requiring a reboot?

 

[Xentrk]

I have "-1" and "30" set in those fields... but setting that to "0" and "-1"... wouldn't that effectively mask problems? And why would I have no problems at all for a week and just start having periodic every 2 hours issues then, requiring a reboot?

There are many variables involved. I saw on one forum a person had this error as well. They were able to eliminate it by changing to another port, which usually means a corresponding change in cipher encryption as well. If you have a LAN to WAN connection to your router with OpenVPN client running, perhaps double NAT is causing you grief. My VPN provider also recommends a -1 and 30 settings in those fields. But I find the 0 and -1 works best for me.

As Merlin stated, "reneg-sec" is the same thing as what is configured under "TLS Renegotiation Time" on the webui. Looking at the reneg-sec option on the openvpn2.3 man page, I highlighted the recommended solution in bold text below:

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).

When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.

Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.

Give it a try. This is also the recommended setting on Yorgi's VPN client setup guide over in the VPN forum. http://www.snbforums.com/threads/ho...ia-and-other-vpn-providers-10-15-fixed.30851/ "The default value may cause the client to be challenged to reauthorize once per hour" according to the man page.

 

[ech]

There are many variables involved. I saw on one forum a person had this error as well. They were able to eliminate it by changing to another port, which usually means a corresponding change in cipher encryption as well. If you have a LAN to WAN connection to your router with OpenVPN client running, perhaps double NAT is causing you grief. My VPN provider also recommends a -1 setting. But I find the 0 works best for me.

As Merlin stated, "reneg-sec" is the same thing as what is configured under "TLS Renegotiation Time" on the webui. Looking at the reneg-sec option on the openvpn2.3 man page, I highlighted the recommended solution in bold text below:

(...snip...)

I used this guide: https://helpdesk.privateinternetacc...ing-up-an-Asus-Router-running-Merlin-Firmware , figuring it was newer and on my VPN provider's site.

But I guess it couldn't hurt to set reneg-sec to 0, and it may actually help, based on the documentation you mentioned. I'd previously searched for the log message errors and only found pages showing people failing to get their connection to work at all, so I suspected there was/is something else going on with my setup, since that wasn't what I was seeing.

 

[tsunami2311]

OK I did some more testing

2g/5g respect the bandwidth limiting, but from some reason some devices that are listed to 10/5 (example) will respect it other device will not respect that despite being listed, IF I remove the device not respecting it and re enter it then it start respecting it . and it seem to happen randomly and when it starts doing that it has to be removed from list and re entered as far as i can tell.

 

[kryptto]

Team,

Thanks Merlin for all your great effort and support of this firmware build. I have loaded the 380.64 a few days back. I own a RT-AC87R, and ever since I have had random disconnects for the 2.4 GHZ radio. The 5 GHZ doesnt drop the connections. Though I do restrict 5 GHZ to a couple of devices. The 2.4 GHZ keeps allowing connections, then the device trying to use the router drops connection. It reconnects then provides connectivity for a few seconds, then cycles through the previous cycle.

I have restored the router then reapplied the settings. Still no better results, does this sound like an issue with the router at this point? Also didnt want to neglect to mention I am using RT-N66U in media bridge mode. I cant say I have noticed it dropping, but I am performing more testing.

I looked through the forums and havent seen any other complaints which lerads me to believe its not necesarily the firmware but maybe a radio hardware issue. Anhy other suggestions are welcomed. I would hate to flash and manually reprogram, too many customized settings.

Thanks all,

Kryptto

 

[kryptto]

Team,

Thanks Merlin for all your great effort and support of this firmware build. I have loaded the 380.64 a few days back. I own a RT-AC87R, and ever since I have had random disconnects for the 2.4 GHZ radio. The 5 GHZ doesnt drop the connections. Though I do restrict 5 GHZ to a couple of devices. The 2.4 GHZ keeps allowing connections, then the device trying to use the router drops connection. It reconnects then provides connectivity for a few seconds, then cycles through the previous cycle.

I have restored the router then reapplied the settings. Still no better results, does this sound like an issue with the router at this point? Also didnt want to neglect to mention I am using RT-N66U in media bridge mode. I cant say I have noticed it dropping, but I am performing more testing.

I looked through the forums and havent seen any other complaints which lerads me to believe its not necesarily the firmware but maybe a radio hardware issue. Anhy other suggestions are welcomed. I would hate to flash and manually reprogram, too many customized settings.

Thanks all,

Kryptto

After some initial testing a reboot allows the connections to stay connected for now. I had seen this in the past, then they start dropping, even after a reboot they might still do this OR stay stable for a bit.

Kryptto

 

[bobiii]

My RT-AC5300 working great for the last 24 hours with alpha 3.

 

[kryptto]

After some initial testing a reboot allows the connections to stay connected for now. I had seen this in the past, then they start dropping, even after a reboot they might still do this OR stay stable for a bit.

Kryptto

Tested the Media Bridge N66U it has the same symptoms as separate connected clients. Just wanted to make sure it wasnt just some issue with the media bridge but appears to have the same issue as individually connected clients.

 

[doczenith1]

Not trying to double post but I thought I'd add this to the official 380.64 thread.

I am seeing an issue with CTF+FA on 380.64 on my 68U. After installing the firmware and doing a reset to defaults I did a very minimal setup. After the minimal setup only CTF was enabled until I did a reboot at which time CTF+FA was enabled. When running a speedtest the test takes about 12 seconds for the test to start and I'm getting around 600-700/200-280 down/up. If I enable Traffic Analyzer - Statistic and then reboot I'm back at only CTF. The speedtest runs normally and I'm back to my normal 940/940 with 100% cpu 1 usage. With stock ASUS firmware (haven't tried any earlier Merlin versions) and CTF+FA enabled I get 940/940 with negligible cpu usage.

Edit: Appears to only be an issue with the Ookla speedtest (firefox and edge). The xfinity flash based test runs fine and the DSLReports HTML5 test run fine.

 

[roscoe211]

I'm getting bouts of this on my AC68U with high CPU usage. Any idea what this is about?

Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: net_ratelimit: 396 callbacks suppressed
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:45 kernel: net_ratelimit: 947 callbacks suppressed

 

[RMerlin]

I'm getting bouts of this on my AC68U with high CPU usage. Any idea what this is about?

Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:35 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: net_ratelimit: 396 callbacks suppressed
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:40 kernel: TCP: time wait bucket table overflow
Dec 29 21:13:45 kernel: net_ratelimit: 947 callbacks suppressed

You have something flooding your router with connections, quite possibly a misconfigured torrent client.

 

[primitivo]

Dual WAN in Load Balancing mode. No device gets Internet connection, even though the router does.

A similar problem used to happen in old firmware versions (both Asus and RMerlin), only in Load Balancing mode and only when both providers were connected. It was related with port forwarding or port trigger (don't remeber exactly). Disabling one of these features would make things work. Later, Asus fixed it and it started working just fine.

In this version I couldn't find any function triggering the problem. I tried clearing settings twice. Then I would start configuring it and it was working until at some point the devices lose access. At this point, no matter which options I turn back to default (including port forwarding and port triggering), it still does not work again. Going back to the previous version fix the problem.

I don't know if it is related, but when the problem happens the interface becomes really slow in Chrome (but not in Firefox).

I checked my dual-WAN in load balancing mode and everything works properly. Try to set fixed DNS servers for both WANs and see if that helps.

 

[ziolupo]

Dear Merlim,
I installed the 380.64 and it's running very well on my AC68U.

Unlucky I have the same (small) problem I was having with the previous firmware.
After a reboot the router is not exporting the mapped NFS file system. I have to manually click "APPLY" in the "NFS Exports" tab and then is starting without any issue.

Thank you for your efford builidng this fantastic firmware!

ZioLupo

 

[eddiec]

Hi, I'm currently on Firmware 374.43_2-22B6j9527. I'd like to flash to the latest 380.64. Can I upgrade it directly or do I have to perform a factory reset first? Thanks.

 

[RMerlin]

Hi, I'm currently on Firmware 374.43_2-22B6j9527. I'd like to flash to the latest 380.64. Can I upgrade it directly or do I have to perform a factory reset first? Thanks.

Factory default reset must be after the flash, not before.

 

[eddiec]

Hmm, with 374.43 I was able to use the VPN Client. After flashing 380.64 the VPN Client can't connect to the internet. I copied all my settings over, what gives?

I did another factory reset and it still doesn't work. I get message:

Error connecting - IP/Routing conflict