What's new

Asuswrt-Merlin 378.50 is out

  • 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!

And I was in firmware recovery mode since I started the router with the reset button held in and the power LED was slowly flashing, correct?

Correct.

And when I ftp-ed the trx file to the router, even though the file transfer was done in 11s, I was in a non-interactive reflash which means I needed to wait a long time before restarting?

The upload copies the firmware to a temporary file inside the router. Once that's done, the router starts the process of (slowly) reading that file, and writing it to the flash partition. That part can take a good 5-15 mins on modern routers, and up to 40 mins on the older N16/N66.

Just let it sit there, once the actual flash process is done, the router will reboot itself. You will now by the wireless leds being back on (assuming wireless wasn't previously disabled).

If you do update through the CFE mini website, take the opportunity to select the option to erase the nvram while at it.
 
Last edited:
When I briefly tried the experimental 378.50b_ta_dpi release on my RT-AC56U, the TA graphs didn't work, nor did the URL tracking, and I'm pretty sure I too noticed that my selective routing didn't work.

I know the DPI engine does flush at least the PREROUTING chain in the mangle table, regardless of its content. So the DPI engine can definitely conflict with custom iptables configurations. That's what forced me to ditch my former nat loopback design and return to Asus's own method.
 
Just curious about the DPI implementation. Does it allow QoS to filter P2P packets? Or haven't I undestood anything? :eek:
Also, will it eventually come to the RT-N66U?
Thanks.
 
I know the DPI engine does flush at least the PREROUTING chain in the mangle table, regardless of its content. So the DPI engine can definitely conflict with custom iptables configurations. That's what forced me to ditch my former nat loopback design and return to Asus's own method.

I don't automatically start the VPN Client with the WAN, so as my selective routing is apparently now working, then perhaps any flushing of the iptables by the DPI engine has physically occurred before my customisation, which might explain why the selective routing is working with the DPI engine.

Regards,
 
No. The key word in what I wrote is "TTL"....That's why you need a special TTL serial adapter, to convert the signal/voltages....the router's serial port is on the pcboard. You have to disassemble your router to connect the TTL to serial adapter to it. Thankfully, Asus has soldered pins to it, so you can directly plug the small jumper wires to it, no soldering required.

Ideally, get one that has an integrated serial to USB converter, so you will end up plugging the three small wires on the internal serial port, and the other end to a USB port of your computer.
Super clear, thanks. Disassemble the routers, and we'll find three little TTL-voltage pins on the pcboard. To which we can plug in a cable that can be purchased cheaply with 3 ttl-level socket on one end, and USB on the other. Which Hyperterminal can end up seeing as a COM port, through which we can interact with a Linux prompt on the router.

Really nice of you to explain all this so clearly and concisely, thanks as usual RMerlin.
 
Interesting issue

Well .50 seems like a winner, for the most part. Thanks, as always, to Merlin. I must report a couple of things, however, that I either don't like, or don't understand. Comparing to .43, the power level can only be adjusted from 100%. No more "cheating" with this build. Also, WiFi range and associated speeds on both G and N are significantly lower. With .43 I can be on my patio all the way to the other end of my house and get 50mbps on G, and around 25 on N. With .50, forget about it. G band was lucky to get 3 mbps. I noticed the signal strength was indeed weaker, which, of course, accounts for the slower speeds. I'm back on .43 again and all is fine.

Anyone else seeing this on the N66U?
 
I just sent my RT-AC68U back for repair...
What is not clear to me is what went wrong when I did the factory reset after the update.
I know that this procedure erases the nvram, in my case something went wrong but it happened only with this FW release.
Is that a coincidence or maybe my nvram got faulty?
I want to know from other users here if they had "Turbo mode" enabled or not when they did the upgrade (was it by pressing the led-button or with command line), also if they had already updated the bootloader before like mine.
I want to know also if the "factory default reset" can (or must) be done before or after the update (by pressing reset or from the GUI).
I think it's important to know such informations to avoid future crashing updates like mine and so have a list of things to check before starting the update.
This FW updates also the bootloader so I guess we need to pay more attention.
 
@RMerlin

Update on latest version FW 3.0.0.4.378.50_0, on RT-AC87R
Don't see much difference in performance vs 49 versions.

Lost my IPv6 connectivity. Did not modify any settings after upgrade - any suggestions? It used to work fine on previous version, my ISP Comcast.

Thx

So far I tried all suggestions and IPv6 / Comcast is not working for me on this release.

Anybody else in the same boat?
 
Wireless MAC Filter frequency toggle...

I am on RT-N66 and the Wireless MAC Filter frequency toggle seems to be missing on the Wireless MAC Filter setting page. here's a screenshot. Thought i should report it :] I tried reflashing and factory reseting multiple times nothing worked.

8176e25acb.png
 
Well .50 seems like a winner, for the most part. Thanks, as always, to Merlin. I must report a couple of things, however, that I either don't like, or don't understand. Comparing to .43, the power level can only be adjusted from 100%. No more "cheating" with this build. Also, WiFi range and associated speeds on both G and N are significantly lower. With .43 I can be on my patio all the way to the other end of my house and get 50mbps on G, and around 25 on N. With .50, forget about it. G band was lucky to get 3 mbps. I noticed the signal strength was indeed weaker, which, of course, accounts for the slower speeds. I'm back on .43 again and all is fine.

Anyone else seeing this on the N66U?

Yes this is expected on the N66 on the newer builds. Give John's fork firmware a try you will be impressed with the N66 again.

http://forums.smallnetbuilder.com/showthread.php?t=18914
 
I am on RT-N66 and the Wireless MAC Filter frequency toggle seems to be missing on the Wireless MAC Filter setting page. here's a screenshot. Thought i should report it :] I tried reflashing and factory reseting multiple times nothing worked.

Not a bug. The MAC filtering is a common option now for both bands. No more separate 2.4/5G option.There is info about this somewhere. ASUS implemented that in latest release.
 
Last edited:
Last edited:
Just curious about the DPI implementation. Does it allow QoS to filter P2P packets? Or haven't I undestood anything? :eek:
Also, will it eventually come to the RT-N66U?
Thanks.

The DPI engine is indeed capable of identifying at least some (but not all) of the traffic. I've seen Bittorrent, Bitcomet and uTorrent traffic being detected and classified at times.

The DPI engine will never be available on older MIPS devices, due to the lack of CPU power of these models.
 
Not a bug. The MAC filtering is a common option now for both bands. No more separate 2.4/5G option.There is info about this somewhere. ASUS implemented that in latest release.

Ahh. Okay cool. I didn't read that in merlin's change log and haven't looked at asus'. I am glad they changed that :)
 
TA issue with OpenVPN

I have two identically configured AC68Ps the only difference being that one is an OpenVPN TAP client and the other is the server. TA on the 68P with the running OpenVPN client works fine. TA on the server side never shows any data.
 
Hi

I found an issue on the samba device same.
According to the help an undeline is allowed.
But when I use e.g. Router_Test then it will take the RT-AC66U as the share name. If I use Router-Test then it works.
It looks like using an underline in the device name is not working.

Using underscores in a device/hostname is not recommended as per RFCs. Asus might have allowed it (and so their help popup mentions it), but it's still a bad idea, and shouldn't be used.

I don't want to go through changing 10+ language files to correct the help popup.
 
So far the latest Merlin version seems to be working well on my RT-AC68U, handling wired and wireless clients with no issues that I can see. There is no AP in this network.

However, I've noticed one anomaly regarding the Network Map: the numbers of wired and wireless clients is often incorrect (see attached JPG). I never noticed this effect on the previous Merlin FW. The wireless count (showing 7) is also wrong, as there are only 6 clients at this time. Note that the total (9) is correct, just not divided correctly.

Any thoughts? It's not clear to me whether this is just a cosmetic issue or whether it points to some issue or problem.

That networkmap has always been a major headache. Over the years I've fixed a lot of bugs in it, but now that it seemed to be somewhat reliable, Asus decided to get start adding a lot of fancy stuff on top of it such as wifi/wired, and static/dhcp detection, plus name customization, icon customization, etc... And so it started to introduce new bugs.

I'm starting to feel that Asuswrt's networkmap is turning into a lost cause. Its design make it almost useless on a network with more than 10 devices, as you have to start paging through multiple pages to browse through its list.

The whole thing should be scrapped. The networkmap daemon would have to be rewritten with a more modern coding style. After that, the networkmap need to be changed into something that can display more entries on a single page without having to click on prev/next icons. The Wireless Log page content should be scrapped, and integrated into such a new networkmap.

I might someday try tackling such a project, mostly because it's been bugging me for years. But due to the amount of work involved, I simply lack the time/resources to devote to such a project at this time.
 
Well .50 seems like a winner, for the most part. Thanks, as always, to Merlin. I must report a couple of things, however, that I either don't like, or don't understand. Comparing to .43, the power level can only be adjusted from 100%. No more "cheating" with this build. Also, WiFi range and associated speeds on both G and N are significantly lower. With .43 I can be on my patio all the way to the other end of my house and get 50mbps on G, and around 25 on N. With .50, forget about it. G band was lucky to get 3 mbps. I noticed the signal strength was indeed weaker, which, of course, accounts for the slower speeds. I'm back on .43 again and all is fine.

Anyone else seeing this on the N66U?


Never mind. Upon further research, I have discovered that the FCC and Netgear ganged up on Asus to force them to lower the range of their routers. So any firmware from Merlin above .43 is boinked. I can confirm on the N66U using .44 or above, the range that allows maximum speed is cut by about twenty feet. Places in my home where I can get 108 mbps dropped to around 45 mbps. No thanks. .43 I stay.
 
There is however a security issue present in the AC87U_378.50 firmware. I've reported it to ASUS already few months ago but still they did not resolve it. Could you please look into it?

I don't see how you are determining that WPS is enabled - Wifi Analyzer does not mention anything related to WPS with either my RT-AC87U, or any of my neighbours. Can you provide a screenshot?
 
Never mind. Upon further research, I have discovered that the FCC and Netgear ganged up on Asus to force them to lower the range of their routers. So any firmware from Merlin above .43 is boinked. I can confirm on the N66U using .44 or above, the range that allows maximum speed is cut by about twenty feet. Places in my home where I can get 108 mbps dropped to around 45 mbps. No thanks. .43 I stay.

How are you getting those numbers? Is that the indicated connection speed?

What device are you using as your test? Hope that it's a laptop. I would test with actually copying a large file from a wired computer to see if the performance has dropped or not.

Staying with .43 is not an option with the many bug fixes, security issues and other improvements the newer versions offer, and offer continuously.

You may be setting up your network as a bot net for who knows who...
 

Sign Up For SNBForums Daily Digest

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