[Release] Asuswrt-Merlin 380.66 is now available

[MissingTwins]

Just had my RT-AC88U stop responding to all network traffic out (LAN and WAN) of the blue. I was streaming a YouTube video over wifi on my iPad and I noticed it started to stutter a bit and then stopped playing altogether. At that point all wired and wireless devices lost access to the Internet and none could ping the router itself. I tried pinging from the WAN side and that had no response either. Basically the router wasn't responding to any network traffic. I had to power it off and on.

I upgrade to 380.66_4 on May 27th early morning and up till it died it was fine. I checked the log and there was nothing between May 27 and the time it booted up after I powered it on.

I've read a few other reports of this happening to others in the thread, so it seems likely there's a bug in this firmware.

Of note I ran 380.65_2 for several months without issue. I ran 380.66 for about a week before I had to reboot. Similar with 380.66_2.

Have you tried Naftali Oziel's suggestion? Reset NRAMs settings and re-setup from scratch?

Mine ac68u had similar sudden death and weird behaviors. It's OK now, after factory reset.

 

[Morac]

Have you tried Naftali Oziel's suggestion? Reset NRAMs settings and re-setup from scratch?

Mine ac68u had similar sudden death and weird behaviors. It's OK now, after factory reset.

I haven't, but it's been up 4 days now without issue. If it happens again, ill trying setting things up from scratch, but I don't customize much in the first place and have never had to factory reset before. It seems like the 380.66 version requires powering off the router periodically for some reason when before it did not. I haven't run any version of 380.66_x for more than a week, but I've never had the router lock up completely before 4 days ago.

 

[MissingTwins]

I haven't, but it's been up 4 days now without issue. If it happens again, ill trying setting things up from scratch, but I don't customize much in the first place and have never had to factory reset before. It seems like the 380.66 version requires powering off the router periodically for some reason when before it did not. I haven't run any version of 380.66_x for more than a week, but I've never had the router lock up completely before 4 days ago.

Well, you really should do a factory reset, it will fix once and for all, since you don't customize much, it won't cost much too.

I updated from 380.65, I had none issue for months and never had to power cycle the router. After update to 380.66_x I though it would be fine without factory reset, but I was wrong.

 

[galen2]

I have a lot of dns problems when i go into a web, first dns failed screen appears on chrome and 2sg before web appears. When i reboot the AC66U the problem is solved for a short time, them this problem appears again. I changed default dns from my operator to google, disabled upstream dns but problem persist. I had reset to defaults and configure again and still same.

 

[WBV]

I'm currently running 380.66_4 on my RT-AC5300 and having intermittent VPN drops. I have posted about this before and tried several suggestions that did not help. I recall that 380.64_2 was the last release that had a stable VPN. Here's a snippet of my log file for what it's worth.

 

[Xentrk]

I'm currently running 380.66_4 on my RT-AC5300 and having intermittent VPN drops. I have posted about this before and tried several suggestions that did not help. I recall that 380.64_2 was the last release that had a stable VPN. Here's a snippet of my log file for what it's worth.

Please post a picture of your OpenVPN GUI page. I will compare with my settings to see if I can help.

 

[amd7674]

Hi All,

Thank you Merlin for you continuous support

I'm happy user with 380.66 on my 1900P (AC68U fw). I think I only use AIprotection for my kidds from advanced features, i.e I don't use VPN.

Is there a benefit to upgrade to 380.66_4? In the past I was doing straight fw. upgrade. From my understanding with this firmware I have to factory reset and redo all my settings from scratch? My wife/kids for school depend on internet and I would like to avoid any "long" down time

Thanks in Advance.

 

[WBV]

Please post a picture of your OpenVPN GUI page. I will compare with my settings to see if I can help.

I could do that but my settings are the same as they were with 380.66
There were some strange events in the log file I attached. That did not help ?

 

[RMerlin]

Is there a benefit to upgrade to 380.66_4?

Security fixes in 380.66_4, so it's recommended.

From my understanding with this firmware I have to factory reset and redo all my settings from scratch?

Only if specifically mentioned in the documentation, if coming from a much older version, or if encountering odd issues.

 

[amd7674]

Security fixes in 380.66_4, so it's recommended.

Only if specifically mentioned in the documentation, if coming from a much older version, or if encountering odd issues.

Thanks I will try to do it tonight I will report back.

 

[Xentrk]

Please post a picture of your OpenVPN GUI page. I will compare with my settings to see if I can help.

Based on the first error message, make sure TLS Renegotiation Time is set to 0 (zero) and see if that helps.

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

 

[WBV]

Based on the first error message, make sure TLS Renegotiation Time is set to 0 (zero) and see if that helps.

I have now done this. You are correct about re-authorization occuring every hour. I have also locked down compression to LZO only and legacy fallback cipher to AES-256-CBC as listed in my provider's config file. I appreciate the info. Thanks

 

[Xentrk]

I have now done this. You are correct about re-authorization occuring every hour. I have also locked down compression to LZO only and legacy fallback cipher to AES-256-CBC as listed in my provider's config file. I appreciate the info. Thanks

You're very welcome. Glad that helped. I forgot to mention the other two settings. I don't enable cipher negotiation as well as cipher and port are a one to one relationship with my provider. I used to use compression of none. But with OpenVPN 2.4, I found I had to enable LZ0 adaptive, which is the recommendation of my provider anyway. Happy you got it working!

 

[mystical]

I realize that these consumer grade routers will never be ideal but I do regret buying this RT-AC88U. Since that incident I've turned off dual WAN putting it solely on the primary WAN as it should've migrated to the second ISP if the primary went down which it didn't.

I didn't save the log before I flashed and cleared it out so everything currently there is for the 380.66 firmware post flash from yesterday morning.

Dual WAN hasn't worked for me since I upgraded to 66_alpha4 from the 56_ release. The DSL modem attached to the backup port LAN1 continues to function for a laptop connected to the modem, and Merlin reports when I disconnect the LAN1 ethernet cable from the DSL modem. So it appears that Merlin no longer completes the DHCP transaction with LAN1 devices.

 

[galen2]

Hello,

Anyone could explain to me what is the option "bridge multicast snooping", I use iptv with triple vlan and i dont know if i have to activate it or not. please a simple explanation will be enought.

 

[RMerlin]

Hello,

Anyone could explain to me what is the option "bridge multicast snooping", I use iptv with triple vlan and i dont know if i have to activate it or not. please a simple explanation will be enought.

In theory, that feature shouldn't have been enabled in the first place, as it conflicts with the other features that are available on the IPTV page. So I recommend leaving this setting disabled, and instead enable the multicast options on the IPTV page.

I only put the setting there on the Tweaks page in case there were some unexpected issue caused by disabling this feature, but there shouldn't be.

 

[CybMax]

Just upgraded to 380.66_4 today from 380.66_2, and have some weird problems with my linux client(s) that uses ipv6.

This is what the log on the Asus AC68U sais:

Jun  8 21:18:40 dnsmasq-dhcp[488]: DHCPREQUEST(br0) 192.168.0.30 f4:xx:04:95:xx:7c
Jun  8 21:18:40 dnsmasq-dhcp[488]: DHCPACK(br0) 192.168.0.30 f4:xx:04:95:xx:7c Mandark
Jun  8 21:28:47 dnsmasq-dhcp[488]: DHCPREQUEST(br0) 192.168.0.30 f4:xx:04:95:xx:7c
Jun  8 21:28:47 dnsmasq-dhcp[488]: DHCPACK(br0) 192.168.0.30 f4:xx:04:95:xx:7c Mandark

As you see, this happens every 10 minutes (Yeah, got a lot of previous logs showing exactly 10 minute intervals, but cba to post and has mac's on them all...)

This is in syslog on the linux box:

Jun  8 21:28:50 Mandark NetworkManager[1127]: <info> (eth0): DHCPv6 state changed nbi -> renew6
Jun  8 21:28:50 Mandark NetworkManager[1127]: <info>   nameserver '2001:xxxx:xxxx::1'
Jun  8 21:28:50 Mandark NetworkManager[1127]: <info>   domain search 'dexter.no.'
Jun  8 21:28:50 Mandark NetworkManager[1127]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 21:28:50 Mandark NetworkManager[1127]: <info> (eth0): DHCPv6 client pid 5680 exited with status 0
Jun  8 21:28:50 Mandark NetworkManager[1127]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 21:28:51 Mandark NetworkManager[1127]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv6 routing and DNS.
Jun  8 21:28:51 Mandark NetworkManager[1127]: <info> Writing DNS information to /sbin/resolvconf
Jun  8 21:28:51 Mandark dnsmasq[2068]: setting upstream servers from DBus
Jun  8 21:28:51 Mandark dnsmasq[2068]: using nameserver 192.168.0.1#53
Jun  8 21:28:51 Mandark dnsmasq[2068]: using nameserver 2001:xxxx:xxxx::1#53
Jun  8 21:28:51 Mandark NetworkManager[1127]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.

This happens every 10 minutes, and causes the "network manager" on my linux box to take the link down - ie i loose internet connection for a couple of seconds every 10 minutes

Jun  8 16:04:02 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:04:02 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:04:03 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 16:14:10 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:14:10 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:14:11 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 16:24:16 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:24:16 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:24:17 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 16:34:21 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:34:21 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:34:22 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 16:44:28 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:44:28 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:44:29 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 16:54:35 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:54:35 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:54:36 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 17:04:42 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 17:04:42 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 17:04:43 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 17:14:49 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 17:14:49 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 17:14:50 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 17:24:54 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 17:24:54 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 17:24:55 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.

I have power cycled the box and everything but to no avail. Could not really see what has changed from 380.66_2 -> 380.66_4 regarding any dhcp changes, but maybe a new bug?

Tested this on 2 different linux boxes, one with kernel 4.11 (custom), and other with kernel 4.4 (release ubutu)

Thoughts?

C

 

[Naftali Oziel]

Just upgraded to 380.66_4 today from 380.66_2, and have some weird problems with my linux client(s) that uses ipv6.

This is what the log on the Asus AC68U sais:

Jun  8 21:18:40 dnsmasq-dhcp[488]: DHCPREQUEST(br0) 192.168.0.30 f4:xx:04:95:xx:7c
Jun  8 21:18:40 dnsmasq-dhcp[488]: DHCPACK(br0) 192.168.0.30 f4:xx:04:95:xx:7c Mandark
Jun  8 21:28:47 dnsmasq-dhcp[488]: DHCPREQUEST(br0) 192.168.0.30 f4:xx:04:95:xx:7c
Jun  8 21:28:47 dnsmasq-dhcp[488]: DHCPACK(br0) 192.168.0.30 f4:xx:04:95:xx:7c Mandark

As you see, this happens every 10 minutes (Yeah, got a lot of previous logs showing exactly 10 minute intervals, but cba to post and has mac's on them all...)

This is in syslog on the linux box:

Jun  8 21:28:50 Mandark NetworkManager[1127]: <info> (eth0): DHCPv6 state changed nbi -> renew6
Jun  8 21:28:50 Mandark NetworkManager[1127]: <info>   nameserver '2001:xxxx:xxxx::1'
Jun  8 21:28:50 Mandark NetworkManager[1127]: <info>   domain search 'dexter.no.'
Jun  8 21:28:50 Mandark NetworkManager[1127]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 21:28:50 Mandark NetworkManager[1127]: <info> (eth0): DHCPv6 client pid 5680 exited with status 0
Jun  8 21:28:50 Mandark NetworkManager[1127]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 21:28:51 Mandark NetworkManager[1127]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv6 routing and DNS.
Jun  8 21:28:51 Mandark NetworkManager[1127]: <info> Writing DNS information to /sbin/resolvconf
Jun  8 21:28:51 Mandark dnsmasq[2068]: setting upstream servers from DBus
Jun  8 21:28:51 Mandark dnsmasq[2068]: using nameserver 192.168.0.1#53
Jun  8 21:28:51 Mandark dnsmasq[2068]: using nameserver 2001:xxxx:xxxx::1#53
Jun  8 21:28:51 Mandark NetworkManager[1127]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.

This happens every 10 minutes, and causes the "network manager" on my linux box to take the link down - ie i loose internet connection for a couple of seconds every 10 minutes

Jun  8 16:04:02 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:04:02 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:04:03 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 16:14:10 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:14:10 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:14:11 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 16:24:16 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:24:16 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:24:17 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 16:34:21 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:34:21 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:34:22 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 16:44:28 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:44:28 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:44:29 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 16:54:35 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 16:54:35 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 16:54:36 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 17:04:42 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 17:04:42 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 17:04:43 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 17:14:49 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 17:14:49 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 17:14:50 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.
Jun  8 17:24:54 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled...
Jun  8 17:24:54 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started...
Jun  8 17:24:55 Mandark NetworkManager[1129]: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete.

I have power cycled the box and everything but to no avail. Could not really see what has changed from 380.66_2 -> 380.66_4 regarding any dhcp changes, but maybe a new bug?

Tested this on 2 different linux boxes, one with kernel 4.11 (custom), and other with kernel 4.4 (release ubutu)

Thoughts?

C

hard reset and re-configuration may do the trick.

 

[CybMax]

hard reset and re-configuration may do the trick.

Well.. Id be happy to NOT to set everything up again... while everyone in the house screams cos they dont have internet. I have done many "minor" upgrades without doing a fresh setup - from 3xx.yy_1 -> 3xx.yy_2 and such where the changes are just minor bug fixes without problems in the past. Any solution to a computer problem is also always "solved" with "Why dont you do a fresh install", but its hardly a solution

However, i did restart the dnsmasq service manually, and it seems to have improved the situation. There is a thing i wonder tho:
In my /tmp/etc/dnsmasq.conf i have a line reading:

dhcp-range=lan,::,constructor:br0,ra-stateless,64,600

Doesn't this kinda mean that ipv6 lease time is 600 sec (ie. 10 min)? Should it not be default of 86400 sec?

C

 

[GoNz0]

Well.. Id be happy to NOT to set everything up again... while everyone in the house screams cos they dont have internet. I have done many "minor" upgrades without doing a fresh setup - from 3xx.yy_1 -> 3xx.yy_2 and such where the changes are just minor bug fixes without problems in the past. Any solution to a computer problem is also always "solved" with "Why dont you do a fresh install", but its hardly a solution

However, i did restart the dnsmasq service manually, and it seems to have improved the situation. There is a thing i wonder tho:
In my /tmp/etc/dnsmasq.conf i have a line reading:

dhcp-range=lan,::,constructor:br0,ra-stateless,64,600

Doesn't this kinda mean that ipv6 lease time is 600 sec (ie. 10 min)? Should it not be default of 86400 sec?

C

Give the backup and restore utility a go then, pick the clean install method so it doesn't restore stuff that doesn't apply any more.