[Release] Asuswrt-Merlin 380.66 is now available

[jsmiddleton4]

66_4, anytime it reboots when changing/memorizing a variable it takes FOREVER to realize it has the DHCP/DNS information from my cable modem. This was not an issue with previous versions. Something different with the way it manages the information from the WAN?

 

[MissingTwins]

Suggest you hard reset your router and re-configure from scratch. if this was not done. If it was, revert to your last stable working fw and conduct all your testing again. Had all types of anomalies, hard reset did the trick to resolve.

Thanks a lot. It did the trick.

I did reset to default in the WebUI last night, and had set up everything manually. Before reset my wan-start script did nothing during wan-restore event. After reset It seems working, I can receive notifications email after every reboot.

I will see how long time it will be last without any glitch.

Cheers!

 

[Naftali Oziel]

Thanks a lot. It did the trick.

I did reset to default in the WebUI last night, and had set up everything manually. Before reset my wan-start script did nothing during wan-restore event. After reset It seems working, I can receive notifications email after every reboot.

I will see how long time it will be last without any glitch.

Cheers!

Glad to hear it's working, it should run smoothly. The difference I noticed with this version is when you reset the device airtime fairness is now set to disable by default. You can play with this setting to see if it makes a difference if it's enabled especially if you have older devices but found it useful even if you have all N devices. Trail and error and very specific to everyone's unique environment.

 

[Gregory Phillips]

66_4, anytime it reboots when changing/memorizing a variable it takes FOREVER to realize it has the DHCP/DNS information from my cable modem. This was not an issue with previous versions. Something different with the way it manages the information from the WAN?

I had something similar happen using _2 where it slowed everything down and then finally just cut the connection. Only a reboot would clear it up so at that point I rolled back to the original iteration of it.

 

[jsmiddleton4]

Clearly something is different. Not only did I not drop the WAN information, dhcp/dns server, when it would boot IF the router had to reestablish the WAN information it did so quickly.

Now about the time I think I need to power the cable modem off, the router off, and let everything refresh, the WAN connection reestablishes and I'm good to go.

Its not like I boot the router all the time for some setting change so this isn't a deal breaker. Just that its not right.....

 

[Gregory Phillips]

Now about the time I think I need to power the cable modem off, the router off, and let everything refresh, the WAN connection reestablishes and I'm good to go.

On mine at that point the connection was just so slow and unusable that I had to reboot my router to bring it back in working order. I'm currently running the 67 alpha and haven't had such an issue occur yet.

 

[jsmiddleton4]

No alpha for 68U yet. Which is fine, not complaining. RMerlin will get there when he gets there. Just not there to try yet.

 

[Morac]

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.

 

[Morac]

I noticed this in the boot up log. It normally doesn't show up based on older log entries. Any idea what it is? Could it be related to the router locking up?

Jul 31 20:00:14 kernel: * Invalid signature of oopsbuf: 15-08-93-A0-05-21-D9-46 (len 310982020)

Found another one:

Jul 31 20:00:14 kernel: JFFS2 notice: (444) check_node_data: wrong data CRC in data node at 0x00dab69c: read 0xd8be0691, calculated 0xdd1256e7.

 

[ScottW]

I noticed this in the boot up log. It normally doesn't show up based on older log entries. Any idea what it is? Could it be related to the router locking up?

Jul 31 20:00:14 kernel: * Invalid signature of oopsbuf: 15-08-93-A0-05-21-D9-46 (len 310982020)

See this:
https://www.snbforums.com/threads/rt-ac68u.11366/page-29#post-157047

 

[Morac]

See this:
https://www.snbforums.com/threads/rt-ac68u.11366/page-29#post-157047

Thanks, how about this one?

Jul 31 20:00:14 kernel: JFFS2 notice: (444) check_node_data: wrong data CRC in data node at 0x00dab69c: read 0xd8be0691, calculated 0xdd1256e7.

 

[Morac]

I'm not sure why, but the traffic analyzer is now counting my downloaded WAN data as both downloaded and uploaded. They are nearly identical.

 

[AlpineMan]

Merlin, thanks for all the hard work on our routers. Like a few others here, I've had wifi connectivity issues with 380.66 series....tried all the way to 380.66_4. Had to roll back all my routers to 380.65_4. I have an AC88U as my main router, two AC68U's as repeaters, and AC3100 as media bridge. I wish I had the time to troubleshoot the issues, but my job is getting in the way...the quickest way for me to get back in business was to roll back.

 

[Trebuin]

I have to say that since I upgraded to this build, the wifi capability has been a bit unstable on the 5G side. I have a Netgear extender that has worked perfectly with v65, but upgrading to 66 has caused it to frequently lose connections...still troubleshooting to see if it's just a bad setting somewhere.

 

[returntrip]

I have started using AIProtection since 380.66_4 and I have noticed that a couple of hosts are being flagged by the AIP antivirus:

Alert type : Infected Device Prevention and Blocking
Source : (xx:xx:xx:xx:xx:xx)
Destination : 193.11.114.43

I have inspected the traffic from the "affected" hosts using ntop and I cannot see an attempts to connect to that dest IP.
The funny thing is that I am receiving the same notifications from a Sonos, two adroid tablets and a stock Chromebook.... To me it looks like TrendMicro is at fault.

I have also noticed that when "Infected Device Prevention and Blocking" is ON the router reboots randomly every couple of hours. I have disabled that function and testing as we speak and the router seems up for about 6h now.

Just want to understand if people is having similar issues with this release or if it is AIProtection that is really buggy in general. Thanks.

 

[ech]

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.

Had a similar problem on my AC68U, at just shy of 5 days usage... but after doing the power-cycle (rather than a reboot) I've now been running almost 6 days without a hiccup (on 380.66-2).

 

[GoNz0]

Just had another random login, clicked login and it went to this page after I had logged in

http://192.168.1.1/result_of_get_changed_status_QIS.asp

 

[AndreiV]

I have started using AIProtection since 380.66_4 and I have noticed that a couple of hosts are being flagged by the AIP antivirus:

Alert type : Infected Device Prevention and Blocking
Source : (xx:xx:xx:xx:xx:xx)
Destination : 193.11.114.43

I have inspected the traffic from the "affected" hosts using ntop and I cannot see an attempts to connect to that dest IP.
The funny thing is that I am receiving the same notifications from a Sonos, two adroid tablets and a stock Chromebook.... To me it looks like TrendMicro is at fault.

I have also noticed that when "Infected Device Prevention and Blocking" is ON the router reboots randomly every couple of hours. I have disabled that function and testing as we speak and the router seems up for about 6h now.

Just want to understand if people is having similar issues with this release or if it is AIProtection that is really buggy in general. Thanks.

Fortinet claim that IP is a malware site , they are however the only 1/64 on virustotal .

https://www.virustotal.com/en/url/e...67aa98d2eac706d5f2c520fa/analysis/1496314770/

I run an RT-AC3200 and have AI Protection running, never seen it cause an issue , certainly never had my router reboot.

 

[Tekneek]

I have started using AIProtection since 380.66_4 and I have noticed that a couple of hosts are being flagged by the AIP antivirus:

Alert type : Infected Device Prevention and Blocking
Source : (xx:xx:xx:xx:xx:xx)
Destination : 193.11.114.43

I have inspected the traffic from the "affected" hosts using ntop and I cannot see an attempts to connect to that dest IP.
The funny thing is that I am receiving the same notifications from a Sonos, two adroid tablets and a stock Chromebook.... To me it looks like TrendMicro is at fault.

I have also noticed that when "Infected Device Prevention and Blocking" is ON the router reboots randomly every couple of hours. I have disabled that function and testing as we speak and the router seems up for about 6h now.

Just want to understand if people is having similar issues with this release or if it is AIProtection that is really buggy in general. Thanks.

That IP address was tagged as an Indicator Of Compromise (IOC) in the recent Wanna Cry ransomware attack. However, I believe it is a Tor node. Does it make sense to you that this particular system would be making connections to Tor? If not, I would treat this with a high degree of suspicion.

 

[bbunge]

I went back to version 380.59. Sync is working very well.

I was having some issues with Windows clients not finding my NAS so went back to Asus 380.7378, set up ipv6 and set all DNS servers to Google. And the sync connected!

Sent from my P01M using Tapatalk