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!

Since I have updated to 25e8 I see some traffic on the loopback interface. I have not changed a thing on services or settings. See the graph:
loopback.png


Anyone an idea how to find what causes this? netstat -i doesn't seem to work, even if I install net-tools-netstat.
 
Last edited:
John, I have not used dnscrypt. I will have a look to see if it is enabled or not. Thanks for the suggestion.
 
John, I have not used dnscrypt. I will have a look to see if it is enabled or not. Thanks for the suggestion.
From your sig....did you update from 24e2? I can review the commits to see if anything jumps out.
 
Only way of debugging seemed tcpdump. It seems webserver traffic that causes this.

tcpdump -i lo -vv:

Code:
 asus.<mydomain>.nl.www > asus.<mydomain>.nl.49633: Flags [P.], cksum 0xcae9 (incorrect -> 0xbe7f), seq 1:369, ack 123, win 256, options [nop,nop,TS val 17861 ecr 17861], length 368: HTTP, length: 368
        HTTP/1.0 401 Unauthorized
        Server: httpd
        x-frame-options: SAMEORIGIN
        x-xss-protection: 1; mode=block
        Date: Sat, 01 Jul 2017 17:14:15 GMT
        WWW-Authenticate: Basic realm="RT-N66U"
        Content-Type: text/html
        Connection: close

        <HTML><HEAD><TITLE>401 Unauthorized</TITLE></HEAD>
        <BODY BGCOLOR="#cc9999"><H4>401 Unauthorized</H4>
        Authorization required.
        </BODY></HTML>
19:14:15.363288 IP (tos 0x0, ttl 64, id 3698, offset 0, flags [DF], proto TCP (6), length 52)
    asus.<mydomain>.nl.www > asus.<mydomain>.nl.49633: Flags [F.], cksum 0xe564 (correct), seq 369, ack 123, win 256, options [nop,nop,TS val 17861 ecr 17861], length 0
19:14:15.363514 IP (tos 0x0, ttl 64, id 11255, offset 0, flags [DF], proto TCP (6), length 52)
    asus.<mydomain>.nl.49633 > asus.<mydomain>.nl.www: Flags [.], cksum 0xe55c (correct), seq 123, ack 369, win 265, options [nop,nop,TS val 17861 ecr 17861], length 0
19:14:15.364198 IP (tos 0x0, ttl 64, id 11256, offset 0, flags [DF], proto TCP (6), length 52)
    asus.<mydomain>.nl.49633 > asus.<mydomain>.nl.www: Flags [F.], cksum 0xe55a (correct), seq 123, ack 370, win 265, options [nop,nop,TS val 17861 ecr 17861], length 0
19:14:15.364323 IP (tos 0x0, ttl 64, id 3699, offset 0, flags [DF], proto TCP (6), length 52)
    asus.<mydomain>.nl.www > asus.<mydomain>.nl.49633: Flags [.], cksum 0xe563 (correct), seq 370, ack 124, win 256, options [nop,nop,TS val 17861 ecr 17861]
 
Only way of debugging seemed tcpdump. It seems webserver traffic that causes this.
There's only one thing I can think of. In addition to having the watchdog check if the httpd server is running, I also check that it is responsive by sending it a query. It's been that way for a while. The new part is that I had to change the way I sent the query so that it would pass muster with the CVE-2017-5892 security fix. It may now be showing up as loopback traffic. If you like, I can gen a test build that turns off the check to confirm that's the source.
 
Have you tried V26 beta? With the new samba, some of the performance parameters got 'tweaked'....

I came across another problem, the mtu size that i being supported by my lan devices is 1475 which many times leads to hung file transfers from the disks that i have transferred to a pc. As soon as i increase the ping size from an openvpn client to 1476, the request times out on any device on the lan be it a pc or the router or the pi.

Given how non ideal it is to mess around with mtu size and fragmentation what can i do to know the reason behind why this is not being handled by the devices themselves? I can ping more than 1475 just fine from an openvpn client to website servers like google but it fails with my lan devices.

Edit: more importantly when file transfers had been working without problems on one day what would just cause them to start stalling the next...?

Edit2: never mind, i realise how off topic i am being right now but it's just saddened me after i put in so much effort to get it right.
 
Last edited:
There's only one thing I can think of. In addition to having the watchdog check if the httpd server is running, I also check that it is responsive by sending it a query. It's been that way for a while. The new part is that I had to change the way I sent the query so that it would pass muster with the CVE-2017-5892 security fix. It may now be showing up as loopback traffic. If you like, I can gen a test build that turns off the check to confirm that's the source.

John,
it is not a big deal, it is not much traffic that gets generated. I just noticed it. If it is more secure like this then that's the way it is going to stay. Thanks for clearing this.
 
Hi All,

I am looking to increase the 2.4 Ghz range of my 66u AP, and John's fork appears to be the best firmware candidate for this (and the most active 66u release). Running the latest 380.66 release and the router doesn't go into emergency mode when I try and load John's release, so unable to use the fw restoration facility?

Cheers, Gstadt
 
Hi All,
I am looking to increase the 2.4 Ghz range of my 66u AP, and John's fork appears to be the best firmware candidate for this (and the most active 66u release). Running the latest 380.66 release and the router doesn't go into emergency mode when I try and load John's release, so unable to use the fw restoration facility?
Cheers, Gstadt
Are you doing the procedure correctly?
Probably best to do a normal Reset of the router settings first allowing it to boot up before you start the flashing procedure.

To get into recovery mode on an N66U:
> You want to disconnect/turn off the power i.e. switch on top
> Hold down the Reset button ▶0◀
> Apply the Power
> Once you see the Power light flashing very slowly you can release the Reset button

You want to set a static IP on your computer - say 192.168.1.10.
And then try pinging the router at 192.168.1.1.
You normally get a response of 64 or 100.

It can take some time for the N66U to come back; I normally leave it for at least 10 minutes or more with the power on; longer than the ASUS tool implies.
Most likely worst case scenario is seeing the MiniCFE server page @ 192.168.1.1 - you can also try flashing from there.
I've never been able to kill an N66U and I've tested most of the third party firmwares.
Don't forget to set your computer IP settings back to normal/automatic.
 
Last edited:
So is this the beginning of the end for Merlin/John firmwares or am I overexaggerating?

John doesn't need Asus for his fork, since he's not keeping in-sync with upstream.
 
>The following routers are supported by this firmware:
>N16, N66U, AC66U (original MIPS based revs), AC56U, AC68U (Rev A1,A2,B1) (Rev C1 is NOT supported), >and AC68P (and the retail and color versions, R and W, of each router)

There are no more RT-AC56U routers here in Canada, and the AC68 is rev C1 only, so I can't get any new ARM router to run LTS anymore.

Are there any plans to a new LTS build that could cover some of the new routers in the market?
 
So is this the beginning of the end for Merlin/John firmwares or am I overexaggerating?
Just makes things more difficult for me :( I'm now dependent on how well things are documented in the various CVE databases to try and keep up. Some CVE's have a lot of documentation, including how to recreate the problem. Some are pretty useless. I also won't have access to some of ASUS's solutions, so it's new development time (when it's in the realm of what I can figure out)..
 
There are no more RT-AC56U routers here in Canada, and the AC68 is rev C1 only, so I can't get any new ARM router to run LTS anymore.

Are there any plans to a new LTS build that could cover some of the new routers in the market?

As far as this fork goes, I plan on taking one more crack at updating the SDK to be able to support the later AC68 revs (I've tried twice so far, and haven't been able to get it. BTW....Tomato has the same problem.). Any later models, no plans.
 
An update to the beta for the weekend!

BETA RELEASE: Update-26BA
7-July-2017
Merlin fork 374.43_2-26BAj9527
Download http://bit.ly/1UGjcOX
============================

Following are the major changes (full changelog is in the zip files)

Update-26BA Highlights
  • NEW: Support for IPSET 6 extended set types and options on the AC56/AC68. All set types/options listed in the IPSET 6 help page should now be supported.
  • NEW: Added inactivity timeout for SSH sessions, default set to 20min. This can be changed or disabled via a new option on the Administration>System page. (This has worked correctly in my fork testing as opposed to some problems seen on the latest Merlin builds).
  • Additional coverage for http authentication on 'orphaned' browser sessions.
    Note: When first loading 26BA you will receive an http authentication challenge at the end of the firmware update. Future updates after 26BA will not receive this challenge following the firmware update.
  • A change in the way the 'VPN block routed clients if tunnel goes down' is handled.
    This is no longer enforced if you manually disable(turn off) the VPN client from the gui, but only enforced when the tunnel actually goes down while running. When testing switching between two clients, it was too easy to unexpectantly create conditions that blocked all internet access.
  • An upstream fix for dnsmasq when running in strict mode
    Note: Although dnsmasq 2.77 has been released, IMO it seems a bit unstable. Going to hold off on migrating to the latest build and only migrate selected fixes to my 2.76 'fork' release.
  • Fixes for incorrect trigger rules generation with port ranges and iptables-save of trigger rules.

Update-26B6 Highlights
  • An enhancement to force a revalidation of http credentials after an auto logoff or disconnect
    This turned out to be much more complex than I originally thought, since the original httpd server code had limited awareness when checking credentials that you may haved logged into the web gui from different clients (one at a time). Feedback will be appreciated.
  • A new option to clear existing miniupnpd leases
  • Update with additional fixes included in the latest stable release
    • Fix incomplete/corrupt JFFS backup
    • Fix reversed miniupnpd config external and internal port definitions

Update-26B5 Highlights
  • Updated versions of:
    • OpenVPN to 2.4.3
    • OpenSSL to 1.0.2l
    • miniupnp to 2.0 with a new Port Forwarding syslog page (Any XBox gamers willing to test?)
    • samba - update to 3.6.25 which includes SMB2 support (enable on the USB servers page)
    • nano to 2.8.4
    • dropbear to 2017.75
    • ipset-arm to 6.32
    • avahi to 0.6.32
    • dnscrypt to 1.9.5
    • curl to 7.54
    • ASUS protection server to 380.7627
  • Several backports from the latest Merlin builds

As always, a reminder to have a backup of /jffs in case the jffs space needs to be reformatted due to increases in firmware size.

SHA256
Code:
4c968a4f060bd0f330383a5492e73e17352b69fdcea0eb7e4af2751272c8acaa  RT-AC68U_3.0.0.4_374.43_2-26BAj9527.trx
5a4e2927856f65bab6a93690512379738159b8552717d2a6e3ce4ec4481246e9  RT-AC56U_3.0.0.4_374.43_2-26BAj9527.trx
e642b24d12ff8d556bd80842fb8a1542aacc484b6fe908dc98896279c257d500  RT-N16_3.0.0.4_374.43_2-26BAj9527.trx
99718f1eaa490280964b728435db8c46a2112aaeaa87ea383dc38f41c5c97c44  RT-AC66U_3.0.0.4_374.43_2-26BAj9527.trx
342f671a1756e981ee14121f46763706ebc749760908d26e96439cb5cd75b04d  RT-N66U_3.0.0.4_374.43_2-26BAj9527.trx
 
Last edited:
  • A change in the way the 'VPN block routed clients if tunnel goes down' is handled.
    This is no longer enforced if you manually disable(turn off) the VPN client from the gui, but only enforced when the tunnel actually goes down while running. When testing switching between two clients, it was too easy to unexpectantly create conditions that blocked all internet access.
@john9527 thanks for this!
You know in my current pending issue with nord vpn sometimes I see the vpn client up but cutting internet traffic, sometimes the client appears even disabled in the Gui.

How is the latter going to be seen? Turning itself off and therefore disabling the killswitch is definitely undesired.
But I believe the issue is in the fact that it should never be disabled without explicit use Interaction in the first place.
 
  • Fixes for incorrect incorrect trigger rules generation with port ranges and iptables-save of trigger rules.
Thanks John. I can confirm the Port Triggering is now working for ranges. Tested with TCP and UDP input ranges and TCP trigger (I didn't test a UDP trigger). iptables-save output is now fixed as well. :)
 
As far as this fork goes, I plan on taking one more crack at updating the SDK to be able to support the later AC68 revs (I've tried twice so far, and haven't been able to get it. BTW....Tomato has the same problem.). Any later models, no plans.

Thanks John, this is very promising!

Running LTS has been a fantastic experience, very little stress compared to the plethora of problems that pop up every time there is an upgrade, not just for router firmware. (PLEX, I am looking at you...).

Running Merlin's regular updates was always very stressful, despite Merlin's relentless effort to fix whatever crap ASUS dumped on us, with new problems replacing old ones (or coming back on a regular basis)
 

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