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

john9527

Part of the Furniture
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)
  • 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:
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

Part of the Furniture
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
Without_Ext_AP.png


This is what you see with the option set
With_Ext_AP.png


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

pharma

New Around Here
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

Part of the Furniture
@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?
 

anotherengineer

Regular Contributor
Thanks. Keep the old N66U AP alive!!
 

Maverickcdn

Senior Member
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
Code:
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
Code:
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
 

Maverickcdn

Senior Member
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

Code:
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
 

Maverickcdn

Senior Member
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

Part of the Furniture
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

Part of the Furniture
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

Senior Member
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
Code:
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

Senior Member
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
 
Last edited:

john9527

Part of the Furniture
@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

Senior Member
@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

Part of the Furniture
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

Senior Member
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.
 

Similar threads

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