What's new

[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

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

Thanks for asking the question! I went back and double checked, as I should have picked this up in my upgrade to miniupnpd 2.0 Turns out, I needed an additional 1 line change to be picked up. :oops:

I'll add it for the upcoming V27 release.

BTW, what router are you using?
The AC68U, when is v27 due?
 
May I ask what that one line is please, and is it something already picked up by Merlin?
No, it's a deep, dark secret :D

Just kidding......miniupnpd 2 has a port-in-use function check. The one line change allows it to correctly check the VSERVER chain for conflicts. So this change only affected cases where a upnp forward would conflict with a user manual port forward.

And yes, it's been in Merlin since May of this year (380.66).
 
The AC68U, when is v27 due?
Shortly....it was a big merge to my main branch to pick up the new SDK to support the later revs of the AC68. It's getting some runtime from a group of my pre-release testers now.

But, for everyone to start plannng. On the AC68, this will be the first fork release to require a factory reset and reconfigure after loading due to the SDK/driver changes.. Sorry, but no way around it.
 
On the AC68, this will be the first fork release to require a factory reset and reconfigure after loading due to the SDK/driver changes.. Sorry, but no way around it.
And an initial flash from recovery webserver if coming to this build running a "new"er unit running a later Merlin or Asus build.

We might need to start thinking about putting a drop dead simple process together to follow, or link directly to asus's recovery webserver guide, or even the asus recovery utility since this "step" down seems to be unavoidable.
 
Just kidding......miniupnpd 2 has a port-in-use function check. The one line change allows it to correctly check the VSERVER chain for conflicts. So this change only affected cases where a upnp forward would conflict with a user manual port forward.
Thanks for the info John. I've looked at the change Merlin did (adding --portinuse and using VSERVER). I've also read Merlin's explanation of its effect in another thread from May.

As I understand it, if an application requests that miniupnpd maps a port that is already in use in the VSERVER chain (manual port forwarding) then it returns an error. This doesn't sound quite the same as Asus are describing, "Supported auto dynamic port changing of UPnP server when ports conflict". Marketing speak perhaps, or just BS?:rolleyes:
 
Thanks for the info John. I've looked at the change Merlin did (adding --portinuse and using VSERVER). I've also read Merlin's explanation of its effect in another thread from May.

As I understand it, if an application requests that miniupnpd maps a port that is already in use in the VSERVER chain (manual port forwarding) then it returns an error. This doesn't sound quite the same as Asus are describing, "Supported auto dynamic port changing of UPnP server when ports conflict". Marketing speak perhaps, or just BS?:rolleyes:

BS for me, it didnt fix the issue. I can hear my son now on party chat but he cannot hear me. So frustrating.
 
"Supported auto dynamic port changing of UPnP server when ports conflict". Marketing speak perhaps, or just BS?:rolleyes:
Marketing speak, I think. Once the conflict is detected, either miniupnpd or the application (not sure which) should select another port....'auto dynamic' o_O
 
Marketing speak perhaps, or just BS?

Release notes are written by native Chinese speakers, so sometimes things are lost in the translation.
 
Shortly....it was a big merge to my main branch to pick up the new SDK to support the later revs of the AC68. It's getting some runtime from a group of my pre-release testers now.

But, for everyone to start plannng. On the AC68, this will be the first fork release to require a factory reset and reconfigure after loading due to the SDK/driver changes.. Sorry, but no way around it.
Can we still reconfigure by using your nvram tool, or do we really have to do from scratch?

Thanks
Andi
 
Update-27 is now available!

This release now supports all the AC68U revs (including C1 and E1) and similar routers (AC1900, AC1900P and AC66U_B1).
Special thanks again to @cybrnook and @tracker.ca for testing on these platforms and to @ColinTaylor for testing on the legacy platform.

IMPORTANT: If you are updating an AC56U or AC68U running a fork version V26 or earlier, you will need to perform a factory reset following the firmware update to V27 due to the intergration of the new SDK and related components. Other fork users running an N16, N66U or AC66 can update as normal without a factory reset.

This release also contains enhancements/fixes in

Please take the time to read through the first post of this thread to for some more detailed installation notes and change detail.

Thanks again for everyone's support!


LATEST RELEASE: Update-27E5, including support new rev AC68 class routers
3-September-2017
Merlin fork 374.43_27E5j9527
Download http://bit.ly/1YdgUcP
============================

SHA256
Code:
79aacf9d4b0ed00f7f37de7823c820e7f899319cfa32670ba3bb174fa80c927d  RT-N16_374.43_27E5j9527.trx
793894b52e1e7ac98d5b1c0d54836bf4249afefeabda9397d1b3c72a1fe42009  RT-AC66U_374.43_27E5j9527.trx
012e7dbf1c165ef020f3bb22295093d3f7cda7df546c697810aa71b9b10005bc  RT-N66U_374.43_27E5j9527.trx
001a5e7fd51bdf5caf5083c448c8795b96d979d402b1d8aa5098c5f586515cd4  RT-AC68U_374.43_27E5j9527.trx
c2982f54396b621da6c4f99c4fc29813779e2c5fdf9defb900383774e416c190  RT-AC56U_374.43_27E5j9527.trx
 
Anyone updating an AC68 from v26 please report in. I have one I remotely administer that will be a real pita to walk through having someone fix if there are any hiccups beyond the usual factory reset and reconfigure.
 
Anyone updating an AC68 from v26 please report in. I have one I remotely administer that will be a real pita to walk through having someone fix if there are any hiccups beyond the usual factory reset and reconfigure.

I'm about 1 hour in, coming from V26 on an AC68 Rev B1.
I did the Factory Reset, reconfigured from scratch. No issues to report as of now.
 
Model: RT-AC68U A1
Flashed 27E5 from 26E4

TL;DR
5GHz wifi doesn't seem to be working, 2.4ghz is good though - reverted back to 26E4 for the time being

Longer version
3 hours ago I was running 25E8 and decided to check if the router had a new update: it did and that time, the latest version showing in the first post was 26E4.
I then proceed to update and everything seems to work fine except for the fact that I now cannot be logged in both via wifi and wired: it gives me the "Cannot Login Unless Logout Another User First" message
I come back to this thread looking for a solution and see that OP has updated the latest version to 27E5...
Well, I might as well try it so I make the necessary NVRAM and JFFS backups and flash 27E5.
Everything seems good except for 5GHz wifi, which doesn't show up at all when I scan for networks (scanned with a MBP late 2013 and Galaxy S7E) - 2.4GHz is fine.
I check all settings to make sure everything is correct, factory reset, re-upload my saved JFFS/NVRAM settings etc, nothing seems to do the trick.
One thing I noticed: the only control channel for the 5GHz band I could select was either Auto or 0 - I couldn't select the usual 36/40/44/48 options
After 3 hours of back and forth, I decide to revert back to 26E4 and the moment the firmware is flashed, 5GHz wifi is back.
 
Last edited:
I then proceed to update and everything seems to work fine except for the fact that I now cannot be logged in both via wifi and wired: it gives me the "Cannot Login Unless Logout Another User First" message
That's normal, it's a security feature. Maybe it worked in the past but that was a long time ago.

I check all settings to make sure everything is correct, factory reset, re-upload my saved JFFS/NVRAM settings etc, nothing seems to do the trick.
After doing the factory reset did you re-enter your settings manually, or use John's NVRAM utility? This is required as highlighted in the instruction for this release.
 
That's normal, it's a security feature. Maybe it worked in the past but that was a long time ago.

That's a shame. I wish there was an option to be able to choose the behaviour.

After doing the factory reset did you re-enter your settings manually, or use John's NVRAM utility? This is required as highlighted in the instruction for this release.

I tried to scan for networks right after the factory reset: only the default 2.4ghz "ASUS" ssid was visible, the 5ghz "ASUS_5G" one was not.
After that I uploaded my settings using the web interface - I didn't see anywhere that the John's NVRAM utility was actually required (first post says "may use")
 
I tried to scan for networks right after the factory reset: only the default 2.4ghz "ASUS" ssid was visible, the 5ghz "ASUS_5G" one was not.
Maybe you were too quick. The 5GHz band won't come online until at least 60 seconds after the 2.4GHz band.
After that I uploaded my settings using the web interface - I didn't see anywhere that the John's NVRAM utility was actually required (first post says "may use")
Maybe it could be clearer. "may use" means you may use his utility to restore your settings from backup, but if you don't you will have to re-enter them manually. With this release you cannot use the GUI's "Restore setting (NVRAM)" because of the changes to the wireless driver.
 

Sign Up For SNBForums Daily Digest

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