386.1 Wifi time scheduling

[davelian]

That doesn't mean anything unless you know for certain that 384.19 and 386.1 use identical variables and defaults. Not doing a factory reset AFTER flashing new firmware is a bit like filling up your new car with fuel from your old car: it works fine as long as the new car expects the same fuel, but if it expects Diesel and your old car is gasoline you're going to have a problem. You could switch back and forth between the cars and say "this fuel works fine in my other car, so the problem can't be the fuel," and that wouldn't be accurate.

I think only AC86U have this problem. Tried full reset after 386.1 updated and re-configured the router, but problem is still exist.

 

[Wistuplu]

Hello,
AC86U here.
With 384.18, the Netflix show on the Android TV was stopping a few minutes after the defined limit, probably mostly consuming the content that was buffered in the Netflix app.
With 386.1, I got fancy notifications and messages on an Android Phone (Huawei Mate 9 running Android 9) BUT I could still continue watching Netflix, start YouTube, browse the web etc. I have also retested after a reset.
FYI: With the latest official Asus, 3.0.0.4.386_41634, it properly blocks as expected during the defined time slots, on the same Android phone.
NB: I did understand that the defined time slot covers the blocked period, and not the allowed period. I did have "mobile data" off ;-)

 

[Nano_Cell]

Hello,
AC86U here.
With 384.18, the Netflix show on the Android TV was stopping a few minutes after the defined limit, probably mostly consuming the content that was buffered in the Netflix app.
With 386.1, I got fancy notifications and messages on an Android Phone (Huawei Mate 9 running Android 9) BUT I could still continue watching Netflix, start YouTube, browse the web etc. I have also retested after a reset.
FYI: With the latest official Asus, 3.0.0.4.386_41634, it properly blocks as expected during the defined time slots, on the same Android phone.
NB: I did understand that the defined time slot covers the blocked period, and not the allowed period. I did have "mobile data" off ;-)

I would like to add that I have the same issue with my AC86U. Was working before with 384.19 and now with 386.1 it's not having it. Even blocking outright doesn't seem to be working properly for me. I did a clean upgrade so it's not due to it being dirty. I know Merlin has said before this is closed source and he has no control over it but if you are saying that you have tested the latest official ASUS release and the issue isn't there then maybe that changes things. It is worth tagging him to see?

I would like to say that in my case, when using my AC66U previously, I got this problem almost every other firmware. I wasn't using Merlin's firmware then though.

 

[FelixGV]

Get the same result on my ax86u an OnePlus 7. If log on to WiFi with time scheduled I get auto directed the below webpage.
You can see the icons on top indicateing no internet.
I am writing and posting this reply still seeing the no internet access..

View attachment 30193

That's true. But if you try to use an android phone to access to netflix (also others app), you'll see internet isn't block

 

[OlaP]

I think only AC86U have this problem. Tried full reset after 386.1 updated and re-configured the router, but problem is still exist.

My new Ax86u and old Ac86u has identical time scheduled problems.

 

[davelian]

Just tired latest AsusWRT on AC86u.
Time schedule works perfectly again on both LAN/WiFi connected laptop and Android phone (after Dirty update form 384.19..)!

Will try latest AsusWRT "9.0.0.4.386.41994 Beta Version" on AX86U tonight. But that one doesn't say that parental control is fixed..

*************************************************************
Version 3.0.0.4.386.41634 2021/01/1161.74 MBytes
ASUS RT-AC86U Firmware version 3.0.0.4.386.41634
- Fixed Lets encrypt not working properly.
- Added IPTV supports for specific region.
- Fixed parental control issues.
- Fixed pre-auth RCE chain vulnerability. Special thanks for

Just tired latest AsusWRT on AC86u.
Time schedule works perfectly again on both LAN/WiFi connected laptop and Android phone (after Dirty update form 384.19..)!

Will try latest AsusWRT "9.0.0.4.386.41994 Beta Version" on AX86U tonight. But that one doesn't say that parental control is fixed..

*************************************************************
Version 3.0.0.4.386.41634 2021/01/1161.74 MBytes
ASUS RT-AC86U Firmware version 3.0.0.4.386.41634
- Fixed Lets encrypt not working properly.
- Added IPTV supports for specific region.
- Fixed parental control issues.
- Fixed pre-auth RCE chain vulnerability. Special thanks for Robert Chen.

We are takling about RMerlin version. Not ASUS official firmware.

 

[Nano_Cell]

That's true. But if you try to use an android phone to access to netflix (also others app), you'll see internet isn't block

I think he's saying that exactly. It says his internet is block and yet he's still able to post that message as it's clearly not blocked.

We are takling about RMerlin version. Not ASUS official firmware.

His point is that it's working on the ASUS official version. Merlin has stated before that when it doesn't work there is nothing he can do as it's closed source and he has recommended to test the official ASUS firmware and report it to them. As it's working on the official release then it's possible it's specific to the Merlin release. Maybe we could ask him. Is this something you would be able to shed some light on please, @RMerlin?

 

[RMerlin]

His point is that it's working on the ASUS official version.

He doesn't mention which version he tested, so this is useless information. He most likely tried an older 384_xxxxx version rather than 386_41700 that is used as the basis for my 386.1 release.

 

[Nano_Cell]

Hello,
AC86U here.
With 384.18, the Netflix show on the Android TV was stopping a few minutes after the defined limit, probably mostly consuming the content that was buffered in the Netflix app.
With 386.1, I got fancy notifications and messages on an Android Phone (Huawei Mate 9 running Android 9) BUT I could still continue watching Netflix, start YouTube, browse the web etc. I have also retested after a reset.
FYI: With the latest official Asus, 3.0.0.4.386_41634, it properly blocks as expected during the defined time slots, on the same Android phone.
NB: I did understand that the defined time slot covers the blocked period, and not the allowed period. I did have "mobile data" off ;-)

Thank you for you reply @RMerlin. I have highlighted in bold where he mentions the version he uses and that it works on that version. It does indeed say under the release notes for that version "- Fixed parental control issues.".

 

[Wistuplu]

Hello,

I'm not using 386_41700. I'm not aware it is available from Asus. I'm testing 3.0.0.4.386_41634. This is the latest version mentioned today at https://www.asus.com/us/Networking/RT-AC86U/HelpDesk_BIOS/.

Summary: That current official Asus is not really great anyway for Time Scheduling anyway.

I am just sharing to illustrate the challenge of testing this, and to set some sort of baseline for those who test. I understand that closed source is closed source. And the Merlin and Asus versions are not necessarily in synch regarding the codebase for this; so, today's version A of Merlin might not work exactly like today's version B of official.

With a Chromecast 3, or on a laptop in Wifi in a browser, a Netflix show seems to stop within a few minutes (2 to 4 minutes). This is great and expected. (You expect Netflix to buffer some content. The show was low definition by the way, so maybe there was more "show duration" in the buffer.)
With the Android App on an Android 9 phone, Netflix seems to take 15 to 20 minutes before stopping the show. (Yesterday, it seemed to be much faster at stopping.)
With Android TV (V7, in Ethernet), the show seems to never stop (actually, in one case it stopped 35 minutes after the start of the time window). With Merlin 384.18, it used to stop within a few minutes).

Above, I'm referring to a stream that was started and that should be stopped. If you want to start a new show or new episode, the blocking seems to be immediately effective. And when you lift the rules, the unlocking also happens immediately.

TL;DR: Difficult to test properly.

Peculiarities: My devices are in the 192.168.17.x range. Some devices connect in Wi-Fi, one is cabled. Some rules were defined in the webUI, some in the Android app.
I'm not sure what generates the blocking but some/all of it must come from the stuff below. --dport 80 looks too specific to effectively block all traffic. It would also explain why it would block some stuff "immediately", and not other types of traffic. My approach would be to simply block traffic to all ports. (Update: http://192.168.17.1:18099 is a static web page that announces that the device is blocked. (Search 18099 below.) )

Again, I understand it has nothing to do with Merlin's software. But if one feels adventurous enough to replace the rules ;-) Or if some are willing to share the rules that are generated on various versions, we might be able to understand better which versions have a chance to work or not. See also https://www.snbforums.com/threads/ac68u-time-schedule.58353/#post-513227

aaa@RT-AC86U-4020:/tmp/home/root# iptables -t nat   -n --list PREROUTING
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination   
GAME_VSERVER  all  --  0.0.0.0/0            109.89.xxx.xxx
VSERVER    all  --  0.0.0.0/0            109.89.xxx.xxx
PCREDIRECT  all  --  192.168.17.116       0.0.0.0/0            TIME from 22:30:00 to 23:59:59
PCREDIRECT  all  --  192.168.17.116       0.0.0.0/0            TIME from 00:00:00 to 07:00:00
...
PCREDIRECT  all  --  192.168.17.26        0.0.0.0/0            TIME from 23:00:00 to 23:59:59
PCREDIRECT  all  --  192.168.17.26        0.0.0.0/0            TIME from 00:00:00 to 07:00:00
PCREDIRECT  all  --  0.0.0.0/0            0.0.0.0/0            TIME from 21:00:00 to 23:59:59 MAC A0:10:81:0F:FB:38
PCREDIRECT  all  --  0.0.0.0/0            0.0.0.0/0            TIME from 00:00:00 to 07:00:00 MAC A0:10:81:0F:FB:38
PCREDIRECT  all  --  192.168.17.124       0.0.0.0/0            TIME from 21:00:00 to 23:59:59
PCREDIRECT  all  --  192.168.17.124       0.0.0.0/0            TIME from 00:00:00 to 07:00:00
aaa@RT-AC86U-4020:/tmp/home/root# iptables -t filter   -n --list FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination   
PControls  all  --  192.168.17.116       0.0.0.0/0            TIME from 22:30:00 to 23:59:59
PControls  all  --  192.168.17.116       0.0.0.0/0            TIME from 00:00:00 to 07:00:00
ACCEPT     all  --  192.168.17.116       0.0.0.0/0     
...
PControls  all  --  192.168.17.26        0.0.0.0/0            TIME from 23:00:00 to 23:59:59
PControls  all  --  192.168.17.26        0.0.0.0/0            TIME from 00:00:00 to 07:00:00
ACCEPT     all  --  192.168.17.26        0.0.0.0/0     
PControls  all  --  0.0.0.0/0            0.0.0.0/0            TIME from 21:00:00 to 23:59:59 MAC A0:10:81:0F:FB:38
PControls  all  --  0.0.0.0/0            0.0.0.0/0            TIME from 00:00:00 to 07:00:00 MAC A0:10:81:0F:FB:38
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            MAC A0:10:81:0F:FB:38
PControls  all  --  192.168.17.124       0.0.0.0/0            TIME from 21:00:00 to 23:59:59
PControls  all  --  192.168.17.124       0.0.0.0/0            TIME from 00:00:00 to 07:00:00
ACCEPT     all  --  192.168.17.124       0.0.0.0/0     
ACCEPT     all  --  192.168.17.132       0.0.0.0/0     
ACCEPT     all  --  192.168.17.112       0.0.0.0/0     
ACCEPT     all  --  192.168.17.134       0.0.0.0/0     
ACCEPT     all  --  192.168.17.23        0.0.0.0/0     
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
DROP       all  --  0.0.0.0/0            0.0.0.0/0     
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0     
DROP       all  --  0.0.0.0/0            0.0.0.0/0            state INVALID
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0     
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate DNAT
DROP       all  --  0.0.0.0/0            0.0.0.0/0     
aaa@RT-AC86U-4020:/tmp/home/root#

aaa@RT-AC86U-4020:/tmp/home/root# iptables -S | grep PControls
-N PControls
-A FORWARD -s 192.168.17.116/32 -i br0 -m time --timestart 22:30:00 --timestop 23:59:59 --kerneltz -j PControls
-A FORWARD -s 192.168.17.116/32 -i br0 -m time --timestart 00:00:00 --timestop 07:00:00 --kerneltz -j PControls
...
-A FORWARD -s 192.168.17.26/32 -i br0 -m time --timestart 23:00:00 --timestop 23:59:59 --kerneltz -j PControls
-A FORWARD -s 192.168.17.26/32 -i br0 -m time --timestart 00:00:00 --timestop 07:00:00 --kerneltz -j PControls
-A FORWARD -i br0 -m time --timestart 21:00:00 --timestop 23:59:59 --kerneltz -m mac --mac-source A0:10:81:0F:FB:38 -j PControls
-A FORWARD -i br0 -m time --timestart 00:00:00 --timestop 07:00:00 --kerneltz -m mac --mac-source A0:10:81:0F:FB:38 -j PControls
-A FORWARD -s 192.168.17.124/32 -i br0 -m time --timestart 21:00:00 --timestop 23:59:59 --kerneltz -j PControls
-A FORWARD -s 192.168.17.124/32 -i br0 -m time --timestart 00:00:00 --timestop 07:00:00 --kerneltz -j PControls
-A FORWARD -s 192.168.17.132/32 -i br0 -m time --timestart 23:20:00 --timestop 23:59:59 --weekdays Mon,Tue,Wed,Thu,Fri --kerneltz -j PControls
-A FORWARD -s 192.168.17.132/32 -i br0 -m time --timestart 00:00:00 --timestop 08:00:00 --weekdays Tue,Wed,Thu,Fri,Sat --kerneltz -j PControls
-A PControls -i br0 -o br0 -j DROP
-A PControls -m state --state INVALID -j DROP
-A PControls -j DROP
aaa@RT-AC86U-4020:/tmp/home/root# iptables -t nat -S PCREDIRECT
-N PCREDIRECT
-A PCREDIRECT -s 192.168.17.116/32 ! -d 192.168.17.0/24 -i br0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.17.1:18099
...
-A PCREDIRECT -s 192.168.17.26/32 ! -d 192.168.17.0/24 -i br0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.17.1:18099
-A PCREDIRECT ! -d 192.168.17.0/24 -i br0 -p tcp -m tcp --dport 80 -m mac --mac-source A0:10:81:0F:FB:38 -j DNAT --to-destination 192.168.17.1:18099
-A PCREDIRECT -s 192.168.17.124/32 ! -d 192.168.17.0/24 -i br0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.17.1:18099
-A PCREDIRECT -s 192.168.17.132/32 ! -d 192.168.17.0/24 -i br0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.17.1:18099
-A PCREDIRECT -s 192.168.17.112/32 ! -d 192.168.17.0/24 -i br0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.17.1:18099
-A PCREDIRECT -s 192.168.17.134/32 ! -d 192.168.17.0/24 -i br0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.17.1:18099
-A PCREDIRECT -s 192.168.17.23/32 ! -d 192.168.17.0/24 -i br0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.17.1:18099
ojadot@RT-AC86U-4020:/tmp/home/root# nvram show 2>/dev/null | grep ^MULTIFILTER
MULTIFILTER_ALL=1
MULTIFILTER_ENABLE=1>1>1>1>1>1>1>1>1
MULTIFILTER_MACFILTER_DAYTIME_V2_CONVERTED=1
MULTIFILTER_URL=
MULTIFILTER_URL_ENABLE=
MULTIFILTER_MAC=E4:34:93:B3:1B:F1>FC:DE:90:5D:43:51>5C:5F:67:21:04:9E>A0:10:81:0F:FB:38>58:C5:CB:5E:42:C3>04:5D:4B:E8:AD:2A>50:01:D9:93:0D:8F>44:07:0B:A2:0A:83>D4:6D:6D:B0:B8:8C
MULTIFILTER_DEVICENAME=HUAWEI_Mate_20_Pro-c9607a>Galaxy-A51>TP14>New device>Galaxy-Tab-S2>Sony(android)>HUAWEI_Mate_9-18a9c1644a5>Chromecast>ThinkPad
MULTIFILTER_MACFILTER_DAYTIME=
MULTIFILTER_MACFILTER_DAYTIME_V2=W17F22300700<W03E21000700<W04122000800>W17F20300700<W03E21000700<W04122000800>W17F23000700<W03E21000700<W04122000800>W17F21000700<W03E21000700<W04122000800>W17F21000700<W03E21000700<W04122000800>W07F22202300<W13E23200800<W04123000900>W03E16301900<W04122000800>W03E21000700<W04122000800<W00816001700>W03E21000700<W04122000800<W00817001900
MULTIFILTER_TMP=
aaa@RT-AC86U-4020:/tmp/home/root#

 

[RMerlin]

I'm not sure what generates the blocking but some/all of it must come from the stuff below. --dport 80 looks too specific to effectively block all traffic

That rule is just to display the blocking page, which can only be displayed when someone is trying to access port 80 (as a port 443 redirection would result in just an SSL error, any other port would try to push HTTP code to what is potentially not a web application).

The actual DROP for anything else is done in the filter table, in the PControls chain, which gets processed after the nat table rules that handles just redirection for port 80 traffic.

 

[FxMac]

I am on a AX86 with 386.1, clean factory reset and experiencing the same problems since the earlier beta versions as well. Time scheduling just doesnt work. As noted by many others, BLOCK will indeed block the target client internet access.

However, when i change it to TIME( all day), the target client will show the fancy WIFI page that internet isnt connected but actual testing (speed test) works nonetheless.

 

[Nano_Cell]

I wanted to give this a test with the stock firmware myself but I would have to get up quite early to do it as there are a lot of family using the internet all day. I stay up too bloody late

 

[Wistuplu]

Hello,

Thank you RMerlin for the explanation..

In 384, the PControls chain is targetted (by FORWARD) when the traffic is allowed (e.g. daytime).
In 386, the PControls chain is targetted when the traffic is not allowed (e.g. at night), just the opposite. A look at FORWARD will confirm that. I like "iptables -t filter -vS | grep -E "(FORWARD|PC|NSFW)". The v option will also provide counts of packets and bytes in the output.

In 386, in ASUS official (3.0.0.4.386_41634 and 9.0.0.4.386_41994) , PControls is like

-A PControls -i br0 -o br0 -j DROP
-A PControls -m state --state INVALID -j DROP
-A PControls -j DROP

In 386.1 Merlin, the third rule of PControls on my AC86 targets the NSFW chain instead of DROP, and at least on my router, NSFW is empty. (I'm not sure what settings of the UI would populate NSFW.)

-A PControls -i br0 -o br0 -j DROP
-A PControls -m state --state INVALID -j DROP
-A PControls -j NSFW

With the v option of iptables, one can check that there are indeed packets leaking in that third PControls rule.

Is this different definition of PControls a "feature" of Merlin, a side effect of some setting in the UI, or a feature of the closed source component ?

By the way:
In line with its use for "allowed" timeslices, in 384, PControls was mostly ACCEPT. (Sorry for the alternate formatting.)

Chain​	PControls​	(29​	references)​	​	​	​
target​	prot​	opt​	source​	destination​	​	​
ACCEPT​	all​	--​	0.0.0.0/0​	0.0.0.0/0​	​	​
DROP​	all​	--​	0.0.0.0/0​	0.0.0.0/0​	state​	INVALID​
NSFW​	all​	--​	0.0.0.0/0​	0.0.0.0/0​	​	​
ACCEPT​	all​	--​	0.0.0.0/0​	0.0.0.0/0​	​	​

 

[Wistuplu]

The blocking by Asus is focused on traffic to the internet (-s), not from the internet.
To understand it better, I used:

iptables -t nat   -n --list PREROUTING
iptables -t filter   -n --list FORWARD

and

iptables -t nat  -S | grep -E "(FORWARD|PC|NSFW)"
iptables -t filter  -S | grep -E "(FORWARD|PC|NSFW)"

Actually, lots of traffic to a "parental-controlled" internal device will leak through the following rule
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

To monitor it, I used the following (notice the v for verbose; that will print counters of hits for each rule).

iptables -t nat  -vS | grep -E "(FORWARD|PC|NSFW)"
iptables -t filter -vS | grep -E "(FORWARD|PC|NSFW)"

I'm experimenting with more comprehensive blocking:

iptables -t filter -N PControlsD
iptables -t filter --append PControlsD -j DROP
iptables -t filter --insert FORWARD 1 -m conntrack --ctorigsrc 192.168.17.116/32 -m time --timestart 00:00:00 --timestop 07:00:00 --kerneltz -j PControlsD
iptables -t filter --insert FORWARD 1 -m conntrack --ctrepldst 192.168.17.116/32 -m time --timestart 00:00:00 --timestop 07:00:00 --kerneltz -j PControlsD
iptables -t filter --insert FORWARD 1 -d 192.168.17.116/32  -m time --timestart 00:00:00 --timestop 07:00:00 --kerneltz -j PControlsD

Note that I create PControlsD mostly to allow monitoring of the "hits" counters for each rule with e.g. (Notice the v option. The final grep is used to hide the rules that are never used.)

iptables -t nat  -vS | grep -E "(FORWARD|PC|NSFW)" | grep -v "c 0 0"
iptables -t filter  -vS | grep -E "(FORWARD|PC|NSFW)" | grep -v "c 0 0"

The additional rules above, e.g. with conntrack are meant to stop an ongoing show on Netflix. With the regular Asus Time Scheduling, Netflix will be happy to send you the next 30 minutes of a show if it was started before the start of the blocked timeslice.
BTW: I'm no expert and I can't assess if this conntrack stuff might slow down the router... I hope what I shared might help those who want to experiment. Use at your own risk. Please report your experiences so that we learn together.

(NB: Remember that a firewall restart will "reset" iptables. Your changes will need to go to firewall-start (see https://github.com/RMerl/asuswrt-merlin.ng/wiki/User-scripts )

 

[homeofwind]

I had same questions regarding parent control block scheduling: seems it is not blocking most of the traffic. Can someone share the right way to set the scheduled block under 386.1 or it is just not fully working? I can only manually block the devices-pretty tiring

 

[Nano_Cell]

The blocking by Asus is focused on traffic to the internet (-s), not from the internet.
To understand it better, I used:

iptables -t nat   -n --list PREROUTING
iptables -t filter   -n --list FORWARD

and

iptables -t nat  -S | grep -E "(FORWARD|PC|NSFW)"
iptables -t filter  -S | grep -E "(FORWARD|PC|NSFW)"

Actually, lots of traffic to a "parental-controlled" internal device will leak through the following rule
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

To monitor it, I used the following (notice the v for verbose; that will print counters of hits for each rule).

iptables -t nat  -vS | grep -E "(FORWARD|PC|NSFW)"
iptables -t filter -vS | grep -E "(FORWARD|PC|NSFW)"

I'm experimenting with more comprehensive blocking:

iptables -t filter -N PControlsD
iptables -t filter --append PControlsD -j DROP
iptables -t filter --insert FORWARD 1 -m conntrack --ctorigsrc 192.168.17.116/32 -m time --timestart 00:00:00 --timestop 07:00:00 --kerneltz -j PControlsD
iptables -t filter --insert FORWARD 1 -m conntrack --ctrepldst 192.168.17.116/32 -m time --timestart 00:00:00 --timestop 07:00:00 --kerneltz -j PControlsD
iptables -t filter --insert FORWARD 1 -d 192.168.17.116/32  -m time --timestart 00:00:00 --timestop 07:00:00 --kerneltz -j PControlsD

Note that I create PControlsD mostly to allow monitoring of the "hits" counters for each rule with e.g. (Notice the v option. The final grep is used to hide the rules that are never used.)

iptables -t nat  -vS | grep -E "(FORWARD|PC|NSFW)" | grep -v "c 0 0"
iptables -t filter  -vS | grep -E "(FORWARD|PC|NSFW)" | grep -v "c 0 0"

The additional rules above, e.g. with conntrack are meant to stop an ongoing show on Netflix. With the regular Asus Time Scheduling, Netflix will be happy to send you the next 30 minutes of a show if it was started before the start of the blocked timeslice.
BTW: I'm no expert and I can't assess if this conntrack stuff might slow down the router... I hope what I shared might help those who want to experiment. Use at your own risk. Please report your experiences so that we learn together.

(NB: Remember that a firewall restart will "reset" iptables. Your changes will need to go to firewall-start (see https://github.com/RMerl/asuswrt-merlin.ng/wiki/User-scripts )

I would be interested to see if this works myself but as I'm even less of an expert than you it will take a bit of learning what the hell all this means first. I'll get there ;-)

 

[dh99999]

Is this different definition of PControls a "feature" of Merlin, a side effect of some setting in the UI, or a feature of the closed source component ?

I can confirm I am seeing the same difference between stock and Merlin that is reported above - TIME based Parental Controls are not working - AC86U.

iptables also shows NSFW in lieu of DROP for PControls.

-A PControls -i br0 -o br0 -j DROP
-A PControls -m state --state INVALID -j DROP
-A PControls -j NSFW

 

[tun]

RT-AC68U time schedule not working for me either, back to 384.19

 

[mvadu]

I am on AC-3100 as main and AC-86U as mesh node. Kids windows PC is the target

So, you're using the 'app' to do this? Does it work when using a browser on a PC?

I am on AC-3100 as main and AC-86U as mesh node. Kids windows PC is the target device. I am updating the time schedules using the browser on my PC.
When the schedule hits, Windows network checking code thinks it lost connectivity at the set times, and all other apps continue to work just fine.