What's new

[Release] Asuswrt-Merlin 384.16 (and 384.13_6) are 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!

Status
Not open for further replies.
Upgrade on both my 68U and 86U went off without a hitch (event with USB drives plugged in).
 
After 24hrs my Ram usage has plummeted to 73%. Baseline in forever has been about 90+%. Examing processes looks like everything is running as expected. Syslogs show nothing. Wondering if the Ram data reporting method has changed.
 
Who uses the USB 3.0 connector? Does the flash drive work with firmware 384.16?
ASUS RT-AC68U does not work.
My AC86U has a 1 TB SSD in the USB 3.0 slot set to USB3, used for some file storage (2Mb) and Apple TimeMachine, and a USB 3.0 in the USB2 slot with AMTM. Skynet, Diversion, and the utis in my sig. Never had a USB not working issue in 3 years with N66u, AC68U or AC86U. AX88U on the way.
 
In the last couple of days since 384.16_0 has been available, I have been busy updating a handful of each of the usual suspects. RT-AC66U_B1's, RT-AC68U's, RT-AC3100's, RT-AC86U's and a few RT-AX88U's too.

All were 'dirty' upgrades (social distancing and all).

Some from 384.16 Beta 2 or 3, most from 384.15_0.

No issues, no drama (not even with almost 30 RT-AC86U's and the infamous 'rebooting' issue). The 2x RT-AC86U RMerlin powered (main and node) AiMesh network was also updated with no problems. All very straightforward and evidence to the meticulous coding RMerlin and all the script authors do.

The steps below outline what I did for each router upgrade regardless of firmware installed and regardless if a USB drive was in use or not). Note that over half of these upgrades were done remotely over OpenVPN with the customer turning on the server and turning it off afterward and being in contact either via cell phone or texting.

  • Whether additional scripts were used or not, I updated amtm to version 3.1.6 FW.
  • Most 'script' updates were minor, such as for Unbound v2.18 and Skynet v7.15 (done in that order).
  • In the router GUI, I 'Safely removed' the USB drives (note; these were not physically removed from the router).
  • After the CPU's settled down from doing the above, I flashed the appropriate firmware for each router).
  • After the reboot completed, I check that the upgrade 'took', and check that the scripts are working and still up-to-date.
  • My part was finished at this point, but after an additional 15 to 60 minutes, I instructed the customers to reboot their router one more time. I trust they did.
With the above simple steps, the routers and the network were down for a bare minimum of time. And the benefits are the improved security, performance, and stability each firmware upgrade offers.

@RMerlin, on behalf of my small corner of the world. A sincere thank you from one and all.
 
Who uses the USB 3.0 connector? Does the flash drive work with firmware 384.16?
ASUS RT-AC68U does not work.
I use USB 3.0 connector and USB Mode is USB 3.0.

I have a passive USB 2.0 hub connected to the USB 3.0 connector of my router, and two usb flash drives (USB 2.0) connected to the hub. Both drives seem to work just fine atm with fw 384.16 (dirty flash of course because I am a dirty old man :p).
 
For some reason, all the script writers for RMerlin's firmware recommend choosing USB 2.0. I don't know why, but that seems to be the way it is.
 
Just one question.
On WAN -> DNS-over-TLS, why do we have to provide IP address?
For example, I want to put "dns.nextdns.io", but I have to manually look for their IP address (which right now is 45.90.28.0, but it can and may change!)
On android, for example, we only have to provide the hostname...

Is this the correct way of implement, or can it be fixed?
 
834.16 beta real-time traffic analyzer wasn't working, came here to report this. Did this get fixed between beta 3 and release?

Edit: flash 834.16, it works again.
 
Last edited:
For some reason, all the script writers for RMerlin's firmware recommend choosing USB 2.0. I don't know why, but that seems to be the way it is.
I was never good at doing what someone told me to do.
Especially if I test and what they tell me not to do works. :p :D
 
Just one question.
On WAN -> DNS-over-TLS, why do we have to provide IP address?
For example, I want to put "dns.nextdns.io", but I have to manually look for their IP address (which right now is 45.90.28.0, but it can and may change!)
On android, for example, we only have to provide the hostname...

Is this the correct way of implement, or can it be fixed?

Using a hostname as a DNS server is like saying you have to call the phonebook printing company to be sent a phonebook - kinda hard to do without the phonebook in hand to lookup up the company's phone number. Therefore, DNS servers are always defined by their IP address, not by their name.

Maybe Google relies on the regular system resolver (or an hardcoded 8.8.8.8) to resolve the hostname, but that is not the proper way to do this.

And no, that IP address will never change, since that is how it is configured in every single router or desktop PC that uses it.
 
The info is still in the changelog. I'm not going to bloat each individual changelogs with 10+ model specific entries, just read past entries, ...

I suggested putting it in the source, not "bloating" the changelog, that's your strawman. Considering that yours is a mod of the stock asus ("The goal of this project is to fix issues and bring some minor functionality adjustments to the original Asus firmware"), the asus version is pretty significant, that's the core and bulk of what one is running.

The source is a natural place for this, it would allow one to find the base version from any commit or tag.
 
I suggested putting it in the source, not "bloating" the changelog, that's your strawman. Considering that yours is a mod of the stock asus ("The goal of this project is to fix issues and bring some minor functionality adjustments to the original Asus firmware"), the asus version is pretty significant, that's the core and bulk of what one is running.

The source is a natural place for this, it would allow one to find the base version from any commit or tag.

Wow really dude?
 
The source is a natural place for this, it would allow one to find the base version from any commit or tag.

It's not that simple, because it's not "a single base version". For instance, the latest release contains pieces from 382_51640, 384_45717, 384_81351, 386_36400, 385_10002, 384_81351, 384_81116, 384_8253, 384_8137 and 384_7977. And I probably missed a few of them...

If you are going to work with the source code, then I recommend using git log --oneline | grep GPL. This is how I was able to track down this list.
 
It's not that simple, because it's not "a single base version". For instance, the latest release contains pieces from 382_51640, 384_45717, 384_81351, 386_36400, 385_10002, 384_81351, 384_81116, 384_8253, 384_8137 and 384_7977. And I probably missed a few of them...

If you are going to work with the source code, then I recommend using git log --oneline | grep GPL. This is how I was able to track down this list.
The pieces fit together like a jigsaw puzzle.
 
Using a hostname as a DNS server is like saying you have to call the phonebook printing company to be sent a phonebook - kinda hard to do without the phonebook in hand to lookup up the company's phone number. Therefore, DNS servers are always defined by their IP address, not by their name.

Maybe Google relies on the regular system resolver (or an hardcoded 8.8.8.8) to resolve the hostname, but that is not the proper way to do this.

And no, that IP address will never change, since that is how it is configured in every single router or desktop PC that uses it.
Great analogy, and I totally understood :)
The DoT hostname to IP conversion could rely on the regular DNS we define a few lines above, but in that case some queries (at least to retrieve DoT IP) would go "unsecured", am I right?
 
Great analogy, and I totally understood :)
The DoT hostname to IP conversion could rely on the regular DNS we define a few lines above, but in that case some queries (at least to retrieve DoT IP) would go "unsecured", am I right?

Correct. And they could potentially be hijacked too, or at the very least blocked.
 
Status
Not open for further replies.

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