What's new

[Release] Asuswrt-Merlin 380.65 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!

I recently updated to the 380.66 alpha build on my AC3200 which completely killed my WAN connectivity (BT Infinity in the UK) so reverted back to what I thought I had as the previous version on the router 380.65_2 after a full reset. Even then I was experiencing WiFi drops and stuttering on audio streaming and wired connectivity packet loss to a server connected through an interim switch.

I've since switched back to 380.65, again after a full reset, but still not entirely convinced the WI-Fi performance is at it should be. In reference to Merlin's quote around AC-3200 build being hacked together due to availability of the closed source components does any one have a view on which version is probably the most stable version to run on this router i.e. includes the best close source drivers etc? I use IPV6, DNS filtering and time restrictions for kids alongside optware to run softlowd to an NTOPNG box to monitor traffic.

Any thoughts gratefully received as I recently switched from a Netgear running a "third party version" of asuswrt merlin but wanted to switch back to an Asus router to benefit from the latest actual Merlin releases having previously owned an Asus router running Merlin for a number of years. So far I haven't been greatly impressed with the 3200 over the Netgear R7000 i switched from but that may be owing to the version of the firmware I have been running.
 
RT-AC3200 here and I see none of the issues you describe.

If a power reset doesn't help try a factory reset and start again.







Please tell us where you have found MU-Mimo settings in your AC3200 ?
Lot of members are having issues with 380-65_2 firmware with AC3200 and mentioned in the thread

The webui is fine with 380-65_0 but is having issues with 380-65_2
 
I encountered a strange bug last night on 380.65 on my AC68u (TM-AC1900). My router stopped working and noticed the LED lights was rebooting. When all the lights were back on, I couldn't use my own IP addressing scheme of 10.x.x.x to access my router. All my settings was reverted back to factory defaults including the IP addresses changing to the default 192.168.1.x. I had to reconfigure all my settings just like turning on the router for the first time.

I have never encountered this problem before or seen my router reset on its own before I used 380.65. I was on 378.56_2.

I wanted to upload my log file but this forum isn't letting me. The date of log showed Aug 1 00:00:18. I would assume that's probably normal first time boot up process of the router before it picks up the NTP and provides the correct date and time.

I can't update to 380.65_2 at the moment. The 380.65 update change my CFE 2.1.2.6. I'll deal with the flashing the CFE later.
 
I encountered a strange bug last night on 380.65 on my AC68u (TM-AC1900). My router stopped working and noticed the LED lights was rebooting. When all the lights were back on, I couldn't use my own IP addressing scheme of 10.x.x.x to access my router. All my settings was reverted back to factory defaults including the IP addresses changing to the default 192.168.1.x. I had to reconfigure all my settings just like turning on the router for the first time.

I have never encountered this problem before or seen my router reset on its own before I used 380.65. I was on 378.56_2.

I wanted to upload my log file but this forum isn't letting me. The date of log showed Aug 1 00:00:18. I would assume that's probably normal first time boot up process of the router before it picks up the NTP and provides the correct date and time.

I can't update to 380.65_2 at the moment. The 380.65 update change my CFE 2.1.2.6. I'll deal with the flashing the CFE later.

sound as though the NVRAM got corrupted. When you upgraded to 380.65 did you than reset to factory settings? It's a big jump going from 378.56_2 to 380.65.
 
sound as though the NVRAM got corrupted. When you upgraded to 380.65 did you than reset to factory settings? It's a big jump going from 378.56_2 to 380.65.

Yes I did it twice, before and after the update. I did the "hold the WPS after powering on method" to reset the NVRAM.
 
I have 4 days of uptime on my RT-AC88U, had zero issue with a 2 hours video stream to my Chromecast last night, neither with my laptop's wifi that was used a few times throughout the past few days. No issue either with my Nexus 9, done a fair amount of web browsing on it last night...

Not using the 8 port one...just the 4 port. But still causes disconnects randomly. I had 1 disconnect today after going back to 380.65, but otherwise stable for the most part.
 
Yes I did it twice, before and after the update. I did the "hold the WPS after powering on method" to reset the NVRAM.

Ok, good approach of resetting NVRAM before and after. Now that is all setup keep track of your NVRAM usage space that it's not hitting max.

To my next assumptions as to your anomaly.

1. Your device is starting to malfunction (potential HW issues).
2. Power spike, ensure your equipment is on a UPS or power surge.

To answer your other question about the boot log time it is normal until NTP is established.
 
Last edited:
@RMerlin on RT-N66U I upgrade it from 380.65 to 65_2 and today this one was reset to factory waiting for admin user/pass input.
On RT-AC87U & RT-AC88U no problems

Sent from SM-G935FD w/Tapatalk
 
Ac3200 same issues with web ui, WiFi, and in my case dns issues on 65_2. Merlin your the best and I appreciate you acknowledging the few of us that that have this router. I'm looking forward to 66.. until then 65 works great.
 
lol all these issues, im glad i own the RT_AC88U same as what merlin uses :) there for better diagnosis before firmare rollout :)
 
Can anyone help me to fix this please!
ScreenShot_20170318235309.png
 
Hi,

I actually using 380.65 on my RT-N66U and I experiencing an issue with a DNS. I have added a record into the hosts on the router via hosts.add script file. When I make nslookup to the host I added it responds correctly. The same happens via web interface from Network Tools. But when I make the same nslookup from the local PC then I get different answer. I already tried to clean DNS cache several time, rebooting PC, ... but nothing helped. My problem is that I have domain name for my external IP and I need to translate my domain name to local IP address instead of the external one. Reason for this is that I do not need to reconfigure all my mobile devices when I'm using them outside or when they are connected to local network. It was working before, when I was on 380.63/64, and I'm not sure if the latest update can break this.

nslookup from router:
nslookup-router.JPG


nslookup from PC:
nslookup-PC.JPG


Any idea how to get it work again? I'm on Windows 10 x64.

Thanks.

PS: It was a Windows issue, and I resolved it by reseting network with this commands:
ipconfig /flushdns
ipconfig /registerdns
ipconfig /release
ipconfig /renew
NETSH winsock reset catalog
NETSH int ipv4 reset reset.log
NETSH int ipv6 reset reset.log

maybe it can help somebody.
 
Last edited:
Just doing another "me too: on 65_2; consistent problems maintaining connections to WAN and connecting via webUI/ssh. rolled back to 65_0 and router is stable now (RT-AC3200)

I'll try the alpha build in a few days.

Yes.


So far, with one notable exception, complains seem mostly related to the RT-AC3200. I'd want to point out that the RT-AC3200 builds are currently hacked together, as Asus failed to provide the closed source components for that model for quite some time. So all the recent AC3200 builds are using older components, with one manual patch I had to apply to make it work with newer GPL code (such as the 3831 code used by 380.64/65/65_2). I suspect that the fact that issues mostly show up with 380.65_2 might be a coincidence, and that this hack'n'patching involved might be the root cause.

Fortunately, GPL 7266 provides all the missing binary components for all models. Unfortunately, some people experience WAN stability issues with 7266, which is currently stopping me from pushing out a new stable release based on it. RT-AC3200 owners might still want to give the 380.66 alpha build a shot, especially as the WAN issue seem to only happen to a small number of people (in my case, it was perfectly stable for the 1-2 weeks that I ran 380.66 code, so once again that's something that I just can't troubleshoot).

Another known issue with 7266 is for people in countries that implement ErP (for example the EU region). Some people's devices end up being stuck in power saving mode. I don't know how widespread the issue is, I haven't seen anyone report the symptoms Asus mentionned to me surrounding that specific issue.
 

Latest threads

Sign Up For SNBForums Daily Digest

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