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!

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).
Wow :eek:, I will do that. With "only" 28 devices on the Network at any given time, this should be a breeze.... LOL.
 
Wow :eek:, I will do that. With "only" 28 devices on the Network at any given time, this should be a breeze.... LOL.
Well, if you take the time to figure out which one, if it happens again next time will really be a breeze :)

I'd start with any IoT type devices.
In my case, it was a HDHomerun Prime if you have any SiliconDust devices.
 
Well, if you take the time to figure out which one, if it happens again next time will really be a breeze :)

I'd start with any IoT type devices.
In my case, it was a HDHomerun Prime if you have any SiliconDust devices.
I think I rebooted all devices especially IoTs, like my Ring cameras, but the problem still persists. Still checking though. :)
 
I've been busy playing with the QoS and iptables stuff (which is working fine for me) and I've come across something that looks wrong while going through the code.

This commit was undoing something from the upstream 2.6.36 kernel code, and has left the fork misaligned:


The removal of the return XT_RETURN; means that the (hacky) --set-return match that is supposed to set the connection and packet mark, then return from the filter chain, isn't returning.

Which means the traditional QoS matching largely won't be working on devices using that kernel - the iptables entries will match, but then it will keep going through the mangle rules, and eventually run the final -A QOSO -j CONNMARK --set-return 0x4/0x1ff that sets priority to low, so making pretty much all traffic low priority, aside from the stuff like ACKs handled over in tc rather than ìptables -t mangle.

I believe the previous code had taken out the return XT_RETURN because the code in ip_tables.c to handle it was missing. It is now there.

HOWEVER, the equivalent code for ip6_tables.c is still missing. (It's present in the 2.6.22 kernel). And that's missing upstream too.

Do you recall what the problem you were fixing in that commit was? Maybe it was IPv6 related?

Looking at it, I suspect traditional QoS rules won't be working on 2.6.36 devices on your fork, and may be cause IPv6 problems on Merlin's version. Devices with other kernels - older or newer - will be fine. Newer kernels dropped the --set-return and devices using them put separate MARK and RETURN entries in their iptables.

Edit: made an upstream PR to restore the missing ip6_tables code. Restoring return XT_RETURN probably depends on that.

https://github.com/RMerl/asuswrt-merlin.ng/pull/794

Edit 2: This may not actually be an issue, because the rc/qos.c on devices with this kernel may already be avoiding using --set-return because of this kernel bug. The manual_return flag is controlling that. Do you think there are any devices with 2.6.36 kernels that wouldn't be setting the flag? It might be safer to remove the kernel additions altogether from 2.6.36 to ensure userspace gets an error, rather than letting them use potentially-flawed kernel code. (This kernel addition was always a hack).
 
Last edited:
Do you recall what the problem you were fixing in that commit was? Maybe it was IPv6 related?
4 years ago? I vaguely remember having a problem, but the specifics escape me (shame on me for not including more detail in the commit).
But, if you look at the context around that commit, it was made as I backported a bunch of system updates from the 380 Merlin release. I *think* that the revert might have been due to problems I was having with the updated CTF, but not sure.
 
4 years ago? I vaguely remember having a problem, but the specifics escape me (shame on me for not including more detail in the commit).
But, if you look at the context around that commit, it was made as I backported a bunch of system updates from the 380 Merlin release. I *think* that the revert might have been due to problems I was having with the updated CTF, but not sure.

I've looked a bit more closely after my edit 3. Your qos.c has partial elimination of --set-return for the AC56 and AC68, but still uses it in some places. It looks like add_bandwidth_limiter_rules avoids it, but add_qos_rules still uses it.

That probably explains why you had a problem.

The latest version in asuswrt-merlin (380) looks similar to yours, so also presumably has a traditional QoS problem on AC56 and AC68, but the very earliest commit to asuswrt-merlin.ng (382) had already eliminated them all.

So I think your current state is that Traditional QoS does not work on those models. None of the user-defined rules entered in the UI will be acted on, cos --set-return doesn't RETURN.

You can fix it either by
  1. inserting the ip6_tables.c kernel code from my PR to asuswrt-merlin.ng and restoring the return XT_RETURN so the --set-returns in mangle_tables (hopefully) work; or
  2. importing 382 qos.c changes from asuswrt-merlin.ng to strip out all use of --set-return on anything other than the N66U and other 2.6.22 devices
Asuswrt-merlin.ng's qos.c got this significant rewrite - so might be easier to compare with an earlier version. Conversion is pretty routine though - almost search-and-replace.

I think I currently favour option 2. The set-return stuff looks like a badly-implemented kernel hack, and it was good that it was removed altogether from later SDK kernels.
 
Last edited:
How you making out? If still having a problem, there is some additional debugging we can try.
Still the same, it's still "Searching" but no Clients appear at all. It shows Clients 0. :oops: I've had the same thing happening with previous updates. I think 49E4 was doing it, if I remember well. The next update 50E8 fixed the problem. It remained fixed until 52E3.
 
Still the same, it's still "Searching" but no Clients appear at all. It shows Clients 0. :oops: I've had the same thing happening with previous updates. I think 49E4 was doing it, if I remember well. The next update 50E8 fixed the problem. It remained fixed until 52E3.
This will be interesting since I haven't touched networkmap in ages.....ssh to the router and

nvram set nmp_debug=2
nvram commit
service reboot

This will dump a LOT of data to the syslog about networkmap. Let it run for a couple of minutes, then upload the syslog somewhere and send me a PM where to look.
 
Welcome to the forums @Asus Maniac.

Yes, security for one. Look at the changelogs since your version to see what has changed so far.
 
This will be interesting since I haven't touched networkmap in ages.....ssh to the router and

nvram set nmp_debug=2
nvram commit
service reboot

This will dump a LOT of data to the syslog about networkmap. Let it run for a couple of minutes, then upload the syslog somewhere and send me a PM where to look.
All right John, now you go a bit over my head. I really don't know how to "ssh" or anything that you are talking about. I fly airplanes for a living...lol! You need to brake it down a bit. ;) I did find this though https://www.htpcguides.com/enable-ssh-asus-routers-without-ssh-keys/ and I'm working on it. Any other help would be appreciated.
 
Last edited:
All right John, now you go a bit over my head. I really don't know how to "ssh" or anything that you are talking about. I fly airplanes for a living...lol! You need to brake it down a bit. ;) I did find this though https://www.htpcguides.com/enable-ssh-asus-routers-without-ssh-keys/ and I'm working on it. Any other help would be appreciated.
The link you have will set up the router.....now for Windows, you can just enable the built in ssh client.....
 

Sign Up For SNBForums Daily Digest

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