What's new

Release [Fork] Asuswrt-Merlin 374 LTS release 52E3

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

(Although maybe it would be possible to knock up a "backport" libip6t_conntrack.c for iptables based on the libxt_conntrack.c from iptables-1.4.x? As far as I can see kernel 2.6.22 has the xt_conntrack support).
Tough to piece together history from almost 10 years ago, but I think we're caught in a sort of catch-22....
IPv6 conntrack originally seems to have come in with 2.6.15 as an experimental feature that needed to be enabled. That would generate a nf_conntrack_ipv6.ko module. That's what I tried to fix in the 52E6 build, but alas, the nf_conntrack_ipv6.ko wasn't generated.

Some further reading says they decided to disable the support after 2.6.20 waiting for the xtables support (which is not in iptables 1.3.8). So, I can't enable the kernel module.

Unfortunately this means you found a new limitation for MIPS....no QoS IPv6 support. The next release will disable the QoS IPv6 code on MIPS (save a bit of processing and get rid of the syslog msgs).
 
Last edited:
Some further reading says they decided to disable the support after 2.6.20 waiting for the xtables support (which is not in iptables 1.3.8). So, I can't enable the kernel module.
"They" being...? Kernel devs? Can't spot it being disabled in the mainline kernel myself. Looks to me like that should be a working module in 2.6.22. Going to check a bit more closely on the asuswrt version.

(Still don't think that iptables 1.3 would support it anyway, mind...)
 
Going to check a bit more closely on the asuswrt version.
Ah, okay. CONFIG_NF_CONNTRACK_IPV6 is already set to "y" in the N66U build, so it's already built-in. I can see the generated nf_conntrack_ipv6.o object file in my not-fully-complete compilation. I guess that overrode your attempt to make it a module.

I think old iptables is the current blocker. Kernel should be able to do the tracking, iptables just can't control it.
 
Oh, and possibly figured out the OpenSSL thing. release/src/router/openssl/Makefile.org is just missing from your Git repo. It doesn't seem to be a generated file.

I'm guessing you've got a local copy and have never checked it in? It's in router/.gitignore so Git wouldn't be pointing that out to you.

Has anyone else done a successful compile from your codebase? Have you tried a clean clone?

Merlin added it here:

 
Been chundering away here. Would like to test iptables-1.4 on the old system at my end, but your Github repo just isn't buildable.

There are quite a lot of missing files - it looks like components have been updated, but due to .gitignore matches, new files from those components haven't been added to Git. I've been filling them in, but I'm still some way from a complete build.

I think you need to try cloning and building and seeing what happens!

Problem areas I've spotted and can recall:

openssl/Makefile.org missing
wget/m4/*.m4 - about 20 files missing
wget/m4/aclocal.m4 - out-of-date
wget/test/* - lots missing
wget/fuzz/Makefile.in - missing
curl/include/curl/options.h - missing
libxml2 - various configuration/automake issues?
libogg - various configuration/automake issues?
libgdbm - problem with $(STRIP) - same as below
openvpn/doc/cipher-negotiation.rst - missing

To confirm - should I be building N66U from src-rt-6.x? Instructions didn't say, and I'd guessed src-rt, but it looks like src-rt-6.x is closer to building.

Anyway, I think I can build iptables-1.4.x in that setup, but I'm nowhere near a runtime test.

Modify router Makefile:
Makefile:
IPTABLES := iptables-1.4.x
IPTC_LIBDIR := $(TOP)/$(IPTABLES)/libiptc/.libs
IPTC_LIBS := -lip4tc $(if $(RTCONFIG_IGD2), $(if $(RTCONFIG_IPV6),-lip6tc,),) -liptc
obj-y += iptables-1.4.x

ifneq ($(or $(findstring linux-2.6.36,$(LINUXDIR)),$(findstring linux-3.x,$(LINUXDIR))),)
obj-y += iproute2-3.x
else
obj-y += iproute2
endif

Also need to fix this:
Makefile:
libnfnetlink/stamp-h1:
# tomatoraf.com, Victek
    cd $(TOP)/libnfnetlink && CC=$(CC) STRIP="$(STRIP)" \

Either need those quotes around $(STRIP) or maybe use $(CROSS_COMPILE)strip like other targets.

And finally you need to copy xf_ethport.h (a Broadcom addition) from srt-rt-6.x.4708/linux/linux-2.6/include/linux/netfilter/ to iptables-1.4.x/include/linux/netfilter/ so it can compile with the older kernel lacking that.
 
Last edited:
Okay, actually managed to produce a .trx file in the end, incorporating iptables 1.4.x. Updated the list of problem code areas above.

Now going to have to pluck up the courage to actually try installing it. Don't have huge confidence that there weren't any quiet failures in the build or that there isn't some vital piece of local magic not in the GitHub repo...
 
Right, my build largely works. o_O

iptables-1.4 doesn't seem to break disastrously at least. The IPv4 NAT and QoS rules work, or at least don't complain in the syslogs.

However, the router's not getting an IPv6 address, and I see no sign of IPv6 activity in the logs, so not sure what it's doing. Thus it never gets around to trying /tmp/mangle_rules_ipv6. But a bit of command probing suggests it would work.

Don't know why IPv6 isn't working. Could be an artifact of the iptables, or something general wrong with my build, what with all the messing it took to get it to go. Haven't tried an old iptables build to compare yet.

I've made a PR to your fork with just the iptables change.
 
Oh, and possibly figured out the OpenSSL thing. release/src/router/openssl/Makefile.org is just missing from your Git repo. It doesn't seem to be a generated file.

I'm guessing you've got a local copy and have never checked it in? It's in router/.gitignore so Git wouldn't be pointing that out to you.

Has anyone else done a successful compile from your codebase? Have you tried a clean clone?

Merlin added it here:

BR
st_ty_
 
  • Like
Reactions: KMO
@st_ty_

When I push the next release, I'll pick up the missing files in a separate commit. I took care of items 3 thru 7, all but....

5. Makefile is missing within pptpd/plugins-folder (/release/src/router/pptpd/plugins) of auswrt-merlin (John fork) repo
There is no Makefile in that folder on my system.

BTW....wget has always been a nightmare..... I've tried several times to fix it in the past
Code:
03bea58fcd wget: add missing files to repo
700bdfd5fa wget: reset tracked files
13a88c82fb wget: update .gitignore, tracked files
5d526e2f1d wget: remove /build-aux from .gitgnore for build

but it looks like git may have been updated since things looked a bit better when I tried this time.

Thanks for the input/help!
 
Last edited:
Sorry to post in a thread about a particular release - but I couldn't figure out where to post for general support, so hopefully someone can point me in the right direction. I'm on an AC66U and have been on Merlin 380.70 for years, which I believe was the final release for this router. I've been having issues with it crashing and just discovered this fork, so wanted to try it, but I get a failure trying to flash - with an error saying that due to regulatory reasons it cannot be flashed. I find this surprising as I'm already on Merlin, not stock. Any ideas?

Full error message: "Invalid Firmware Upload
To comply with regulatory amendments, we have modified our certification rule to ensure better firmware quality. This version is not compatible with all previously released ASUS firmware and uncertified third party firmware. Please check our official websites for the certified firmware."
 
....

5. Makefile is missing within pptpd/plugins-folder (/release/src/router/pptpd/plugins) of auswrt-merlin (John fork) repo
There is no Makefile in that folder on my system.
...
@john9527

Yes, indeed. This file is missing. And that's why my building process stops at pptpd. It complains about "missing Makefile in plugins subfolder". Maybe it is an Artix/Arch Linux related issue, but not one of Debian based systems. I've also got Debian 11 on wsl2/windows, so I can check it.
BR
st_ty_
 
Sorry to post in a thread about a particular release - but I couldn't figure out where to post for general support, so hopefully someone can point me in the right direction. I'm on an AC66U and have been on Merlin 380.70 for years, which I believe was the final release for this router. I've been having issues with it crashing and just discovered this fork, so wanted to try it, but I get a failure trying to flash - with an error saying that due to regulatory reasons it cannot be flashed. I find this surprising as I'm already on Merlin, not stock. Any ideas?

Full error message: "Invalid Firmware Upload
To comply with regulatory amendments, we have modified our certification rule to ensure better firmware quality. This version is not compatible with all previously released ASUS firmware and uncertified third party firmware. Please check our official websites for the certified firmware."
From the installation notes in the original thread linked to from the top here:

For supported routers currently running ASUS firmware 380.3000 or above, or Merlin 380.60 or above, you cannot load this fork using the built in firmware update web interface. You must use the ASUS Firmware Restoration Tool from the ASUS support website or the built in CFE Mini-Web Server to install this fork firmware. You must always perform a factory default reset following the firmware update when moving from ASUS OEM or Merlin firmware above level 374 regardless if you updated via the web interface or Restoration Tool.
 
@john9527

Yes, indeed. This file is missing. And that's why my building process stops at pptpd. It complains about "missing Makefile in plugins subfolder". Maybe it is an Artix/Arch Linux related issue, but not one of Debian based systems. I've also got Debian 11 on wsl2/windows, so I can check it.
BR
st_ty_
I verified that adding that Makefile doesn't break anything on my end, so I'll pick that one up as well. Thanks again.
 
Still fiddling with iptables here and debugging my IPv6 - about to start some reflashing cycles. (At the minute it just looks like I'm getting no response to dhcp6c's IA-PD solicit messages).

Found one user-space incompatibility between the 2.6.22 and 2.6.38 kernels for ip6t_REJECT that I needed to deal with.

One quick note on st_ty's patches, which are otherwise great. Minor nit for item 13, the libxml2/configure.in change - the correct patch is to delete the whole section, and that's what was done upstream.

Code:
--- configure.in    2020-11-16 18:41:43.000000000 +0000
+++ configure.in_mod    2020-11-16 18:38:43.000000000 +0000
@@ -62,7 +62,7 @@
 AC_PATH_PROG(XSLTPROC, xsltproc, /usr/bin/xsltproc)
 
-dnl Make sure we have an ANSI compiler
-AM_C_PROTOTYPES
-test "x$U" != "x" && AC_MSG_ERROR(Compiler not ANSI compliant)
-
 AC_LIBTOOL_WIN32_DLL
 
Right, I seem to be fully functional. It wasn't that straightforward though - the revision 0 xt_conntrack in 2.6.22 does not support IPv6, so I had to backport the revision 1 code from 2.6.25. The revision 0 support was dropped in 2.6.38, which is what would have forced the iptables update. (iptables 1.3.8 supports r0 only; iptables 1.4.14 supports r0-r3).

With ipt6_REJECT adjusted to be the 2.6.38 version, I can use either version of iptables in either kernel. But IPv6 QoS needs the xt_conntrack r1 kernel backport and iptables 1.4.

I've pushed the changes to my PR - feel free to take them or leave them. I don't know if you want to be doing that sort of kernel backport on this fork.

But at least I know how to build my own fork now :)
 
@john9527 Hi John. I've been a long time user of your Firmware on my 68U. After I loaded 52E3, the Client Status doesn't show the Clients list anymore. It keeps rotating and Searching, but non are listing, like previous version did.

Any help with that? I reloaded 51E3, then I put back 52E3 and it's still "Searching"....:oops: while showing Clients 0. Everything connects just fine, but it doesn't show on the interface. I've also rebooted the router a couple of times from the actual switch in the back of it.
 
I verified that adding that Makefile doesn't break anything on my end, so I'll pick that one up as well. Thanks again.
Sorry,
you are right, I'm mistaken: none of the routers needs pptpd (taken from content of target.mak). So, no need to implement this in your repo. Maybe it was a result of former times, when I checked all the rules in all targets of the main Makefile, if they would work with Arch Linux/Artix.
BR
st_ty_
 
It keeps rotating and Searching, but non are listing, like previous version did.
Usually this means that one of your clients is 'stuck' issuing arp requests, which interrupts networkmap. I had one 'always on' device that would flip out like this maybe once a year. I looked at trying to do a fix, but trying to filter the arp code without breaking things got way too complex.

Only thing to do is to go around and reboot everything (one at a time if you want to figure out which one is making trouble).
 

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