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

[john9527]

LATEST RELEASE: Update-52E3
20 October 2021
Merlin fork 374.43_52E3j9527
============================

Update-52E3 Highlights

• NEW: Support for using the router in AP mode attached to an OpenWRT router
  See the file 'OpenWrt-AP.txt' for details
• NEW: Support for USB tethering of Novatel Verizon USB730L (untested)
  
  

  Upstream patch to enable Android tethering (tested: moto g play 2021, potentially: REVVL 5G)

  Hi @RMerlin First, I'd like to thank you for your years of contribution. I purchased Android phone for backup WAN but my AC68U didn't detect it as network interface. After reviewing logs, I found upstream patch and it worked for me. Hence I created PR @...

  www.snbforums.com
• Updated OpenVPN to 2.5.4
• Updated DNSMASQ to 2.86
• Updated DST default start/stop data
• Fixed a problem with stubby logfiles not being properly pruned
• Fixed a problem where specifying WINS server in Samba options was not activated
• Fixed a problem where changing IPv6 settings may not complete
• Fixed a problem where changing static routes may not complete

Full ChangeLog: Changelog.txt in the download directory

Downloads:
https://1drv.ms/f/s!Ainhp1nBLzMJrEayV5NOiKa8zDA3
Folder 'Public-Release/Update-52E3'

Overview / Supported Routers / Installation:

[Fork] Asuswrt-Merlin 374 LTS Overview

ASUSWRT-MERLIN 374 LTS This is an LTS (Long Term Service) fork of Asuswrt-Merlin based on 374.43_2. This older code base has a history of being very stable, and some of the older code components may perform better in some environments. It may be a good choice for those who desire a 'set it and...

www.snbforums.com

or
LTS_OVERVIEW.pdf in the download directory

Previous release threads:
https://www.snbforums.com/threads/fork-asuswrt-merlin-374-lts-release-51e3.74513/
https://www.snbforums.com/threads/fork-asuswrt-merlin-374-lts-release-50e8.73798/
https://www.snbforums.com/threads/fork-asuswrt-merlin-374-lts-release-49E4.72269/
https://www.snbforums.com/threads/fork-asuswrt-merlin-374-lts-release-48e7.71000/
https://www.snbforums.com/threads/f...ease-47eb-rt-ac68u-v3-lets-encrypt-cli.70777/
https://www.snbforums.com/threads/fork-asuswrt-merlin-374-lts-release-46e9-dnspooq.69896/
https://www.snbforums.com/threads/fork-asuswrt-merlin-374-lts-release-46e8-superseded.68757/
https://www.snbforums.com/threads/fork-asuswrt-merlin-374-lts-release-45ec.67509

SHA256
(Default Build - All supported routers)
802ee06b274fa64b19a60bf11b79cef29612e4b8f1b8933704ab412ce77d59a8 RT-N16_374.43_52E3j9527.trx
c1e73a0007642ba109221dcff40f63231443f52656dbac5e8cf6ce63f04d8427 RT-AC66U_374.43_52E3j9527.trx
cf901f25d070c924ef7d2bf1bfc8712610df7cef115f872bfecde186084482f5 RT-N66U_374.43_52E3j9527.trx
1ca1433f27f1760beb4d9b75d0609579084584778c187755d4f625a3030506b9 RT-AC68U_374.43_52E3j9527.trx
e2cbf723c52d982592cdc08f8c837a28106ad9cdf1aecfd1de3f6a65bb66d261 RT-AC56U_374.43_52E3j9527.trx

 

[john9527]

Just in case anyone was wondering what the Extended AP data on LTS Fork/OpenWrt gives you....

This is what you see for Wireless Log for an AP without the option

This is what you see with the option set

You can also see that I've manually configured the AP (an AC1900P) for VLAN support via OpenWrt.....

 

[pharma]

Thanks for the new version! I've seen posts stating that the QOS feature has been broken for quite some time (main Merlin branch) and not sure if work to address this was recently done.
With this version I have good success downloading multiple torrents, watching video streams and web browsing simultaneously on the same PC. Most latency issues I experienced in the past when engaged in multiple activities seems to have gone.

Keep up the good work!

 

[john9527]

@pharma

Thanks for the feedback. I did a lot of work on the traditional QoS sometime back with the help of a couple of forum members to really wring it out. Haven't touched it since....you know the old saying, 'If it ain't broke....

BTW....what router are you running?

 

[pharma]

@john9527

I'm using a RT-N66U for quite a while now. I'm definitely a proponent of that "old saying".

 

[anotherengineer]

Thanks. Keep the old N66U AP alive!!

 

[Maverickcdn]

Question regarding iptables time based rules.....

This rule appears fubar when entered in 374... on 386 it appears normally.... am I doing something wrong or is there different syntax required? It keeps dropping the 0. The rule may work havent had a chance to test yet, but the output leads me to believe it will fail

On 374

MavSEC|>/jffs/scripts| iptables -I FORWARD -s 10.2.2.52 -m time --timestart "05:59" --timestop "06:01" -j DROP
MavSEC|>/jffs/scripts| iptables -L FORWARD -n --line-numbers
Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    DROP       all  --  10.2.2.52            0.0.0.0/0           TIME from 5:59 to 6:1 on all days

On 386

MavMAIN|>/jffs/scripts| iptables -I FORWARD -s 10.2.2.52 -m time --timestart "05:59" --timestop "06:01" -j DROP
MavMAIN|>/jffs/scripts| iptables -L FORWARD -n --line-numbers
Chain FORWARD (policy DROP)
num  target     prot opt source               destination
1    DROP       all  --  10.2.2.52            0.0.0.0/0            TIME from 05:59:00 to 06:01:00 UTC

 

[ColinTaylor]

It might be a cosmetic formatting issue. Look at the output of iptables-save which should give you the "real" rules.

 

[john9527]

This rule appears fubar when entered in 374... on 386 it appears normally

Looking at your sig....are you comparing 386/AC86U output to Fork/N66U? Vastly different iptables levels....
Please do @ColinTaylor 's suggested check to see if it's just a format issue...

 

[Maverickcdn]

It might be a cosmetic formatting issue. Look at the output of iptables-save which should give you the "real" rules.

Formatting issue confirmed, thank you

MavSEC|>/jffs/scripts# iptables-save
# Generated by iptables-save v1.3.8 on Mon Nov  8 13:23:05 2021
....
-A FORWARD -s 10.2.2.52 -m time --timestart 05:59 --timestop 06:01 -j DROP

 

[john9527]

Formatting issue confirmed, thank you

For the next release....
* FIXED: iptables: mips: fix output formatting of timestart/timestop rules

 

[Maverickcdn]

Good day

Would this issue with the time formatting have any affect on the function of the rule?

Having it as the first rule in the chain, using either UTC (should be what it uses yes?) or local time the rule doesn't get hit...

Any ideas

 

[ColinTaylor]

Would this issue with the time formatting have any affect on the function of the rule?

No, it was just cosmetic.

Having it as the first rule in the chain, using either UTC (should be what it uses yes?) or local time the rule doesn't get hit...

What is the offset from UTC to your local time zone?

I can't remember whether the MIPS iptables supports the --localtz or --kerneltz options. You might have to experiment with those.

 

[john9527]

Good day

Would this issue with the time formatting have any affect on the function of the rule?

Having it as the first rule in the chain, using either UTC (should be what it uses yes?) or local time the rule doesn't get hit...

Any ideas

No, wouldn't affect the operation. The change was just a bad integer format descriptor in the printf that printed the data.

 

[Maverickcdn]

What is the offset from UTC to your local time zone?

I can't remember whether the MIPS iptables supports the --localtz or --kerneltz options. You might have to experiment with those.

MST -7

Those options dont appear to work in 1.3.8

MavSEC|>/jffs/scripts| iptables -I FORWARD -s 10.2.2.52 -m time --localtz --timestart "18:30" --timestop "18:40" -j logdrop
iptables v1.3.8: Unknown arg `--localtz'
Try `iptables -h' or 'iptables --help' for more information.
MavSEC|>/jffs/scripts| iptables -I FORWARD -s 10.2.2.52 -m time --kerneltz --timestart "18:30" --timestop "18:40" -j logdrop
iptables v1.3.8: Unknown arg `--kerneltz'
Try `iptables -h' or 'iptables --help' for more information.
MavSEC|>/jffs/scripts| cat /etc/TZ
MST7DST,M3.2.0/2,M11.1.0/2
MavSEC|>/jffs/scripts|

 

[Maverickcdn]

UTC -6 is the magic number for me for whatever reason... I know zero about how time zones work within Linux

On AC86u with 386 straight UTC works

Cannot specify a seconds integer in 1.3.8 either so you need to set 1 min earlier your timestop

 

[john9527]

@Maverickcdn
Couldn't quite tell from you last post....did you get it working? Maybe document what you did?
(I did see that the older iptables didn't support seconds as you noted).

 

[Maverickcdn]

@Maverickcdn
Couldn't quite tell from you last post....did you get it working? Maybe document what you did?
(I did see that the older iptables didn't support seconds as you noted).

Yes it was working but with a different Timezone offset (-6 mine is -7)

But I got home and just had a big aha moment

The issue I believe is kernel time and DST

Router was booted 10 days ago during active DST (-6 UTC). On Sunday we flipped back to MST (-7 UTC).

Everything in the GUI is correct and running the date command from CLI is correct...but

My initial testing worked with -6 offset because kernel TZ was still WITH DST... I rebooted the router without making any changes forcing a Kernel TZ update, and voila back to a working iptables -m time command using current local time (-7 offset)

This is my total newb observation and totally in the dark re kernel level time but Im pretty confident this is the issue I observed with my extremely limited knowledge.... let me know your thoughts

 

[ColinTaylor]

My initial testing worked with -6 offset because kernel TZ was still WITH DST... I rebooted the router without making any changes forcing a Kernel TZ update, and voila back to a working iptables -m time command using current local time (-7 offset)

Yes I think this behaviour is noted in the man page for kerneltz:

The caveat with the kernel timezone is that Linux distributions may ignore to set the kernel timezone, and instead only set the system time. Even if a particular distribution does set the timezone at boot, it usually does not keep the kernel timezone offset - which is what changes on DST - up to date. ntpd will not touch the kernel timezone, so running it will not resolve the issue. As such, one may encounter a timezone that is always +0000, or one that is wrong half of the time of the year. As such, using --kerneltz is highly discouraged.

This was the also point I was alluding to in this post.

 

[Maverickcdn]

Yes I think this behaviour is noted in the man page for kerneltz:

This was the also point I was alluding to in this post.

Ya I got a little bit of reading in at work and it was on the drive home it all came together.

Thanks again for your guidance, you're a wealth of knowledge

and thanks to @john9527 for your attentiveness. Still a great community here.