Ai Protection Parental Time Control not working properly

TheLyppardMan

Very Senior Member
There's something weird going on with the Ai Protection parental control.

I set up a schedule for one of the laptops on my network to go off at 11:00PM (UK Time), but it went off at around 10:00PM instead. Then I set another device, an Android tablet (which doesn't have a SIM card), to go off at 10:15PM, but as 10:15 passed, it still had internet access. Then I set it to "block", rather than time, but it still had internet access.

I'm using an RT-AX88U with the latest Merlin firmware. Is anyone else able to reproduce this?
 

eibgrad

Part of the Furniture
IIRC, those are simply added as firewall rules. Go to an ssh session and dump the FORWARD chain so we can have a look at the rule(s) it generated.

Code:
iptables -vnL FORWARD
 

TheLyppardMan

Very Senior Member
I've disabled all but the test rule I set up for my Android tablet. I set it to disable the internet at 8:30 this evening, but it's now 20:50 as I'm typing this and the tablet still has internet access. I'm uploading the information you requested.
 

Attachments

  • Router Output.txt
    1.8 KB · Views: 87

eibgrad

Part of the Furniture
Well I can see there's nothing pre-empting the rules, so that's good. And I can even see it's using local time as opposed to UTC (which is common mistake). I can even see it's presently getting hits (988 at the time the dump was made).

Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination       
...
  988 60305 PControls  all  --  br0    *       10.0.4.205           0.0.0.0/0            TIME from 20:30:00 to 23:59:59
    0     0 PControls  all  --  br0    *       10.0.4.205           0.0.0.0/0            TIME from 00:00:00 to 07:00:00
...

At least I assume 10.0.4.205 is the intended client. Is that indeed the assigned local IP of the tablet?

BTW, IIRC, I thought AIP uses the MAC address, NOT the IP, since the IP is not as reliable. Not unless that IP has been bound to a specific MAC address using a static lease.

It might have also been useful to have dumped the PControls chain as well (forgot to think of that), just in case there's some issue there.

Code:
iptables -vnL PControls
 

john9527

Part of the Furniture
I set it to disable the internet at 8:30 this evening, but it's now 20:50 as I'm typing this and the tablet still has internet access. I'm uploading the information you requested.
Did you leave your browser open to SNB from before the start time? II think it used to be that the PC rules will only be valid for new connections, not established connections.
 

eibgrad

Part of the Furniture
Did you leave your browser open to SNB from before the start time? II think it used to be that the PC rules will only be valid for new connections, not established connections.

That's not the case for what the OP has reported so far w/ the FORWARD chain. It's NOT qualified w/ state. And these rules are before the normal ESTABLISHED rule. It's why I want to see the PControls chain as well. At least for me, that chain isn't qualified w/ state either.

Code:
Chain PControls (0 references)
pkts bytes target     prot opt in     out     source               destination  
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Seems more likely to me the client the OP is expecting to be 10.0.4.205 (i.e., the tablet) is NOT the device assigned w/ that IP. As I said, that's the issue w/ relying on IP rather than MAC address (and even then, the client could change either of those on the client itself). Consider Apple's privacy feature which randomizes MAC addresses, and thereby the assigned IP. I don't use Android, but given how much they all copycat each other, I assume the same thing is possible w/ them as well.
 
Last edited:

ColinTaylor

Part of the Furniture
@TheLyppardMan You do realise that the clocks just went back an hour? Check that the router's time is correct. You might need to reboot the router even if it looks OK.
 

TheLyppardMan

Very Senior Member
Well I can see there's nothing pre-empting the rules, so that's good. And I can even see it's using local time as opposed to UTC (which is common mistake). I can even see it's presently getting hits (988 at the time the dump was made).

Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination      
...
  988 60305 PControls  all  --  br0    *       10.0.4.205           0.0.0.0/0            TIME from 20:30:00 to 23:59:59
    0     0 PControls  all  --  br0    *       10.0.4.205           0.0.0.0/0            TIME from 00:00:00 to 07:00:00
...

At least I assume 10.0.4.205 is the intended client. Is that indeed the assigned local IP of the tablet?

BTW, IIRC, I thought AIP uses the MAC address, NOT the IP, since the IP is not as reliable. Not unless that IP has been bound to a specific MAC address using a static lease.

It might have also been useful to have dumped the PControls chain as well (forgot to think of that), just in case there's some issue there.

Code:
iptables -vnL PControls
10.0.4.205 is indeed the IP address of the Android Tablet (Cams Monitor in the uploaded screenshot). I'll try the other script in a moment.
 

Attachments

  • Screenshot - 01_11_2021 , 22_09_51.png
    Screenshot - 01_11_2021 , 22_09_51.png
    374.7 KB · Views: 90

TheLyppardMan

Very Senior Member
Here the output from the second script:-

/jffs/scripts$ iptables -vnL PControls
Chain PControls (0 references)
pkts bytes target prot opt in out source destination
0 0 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0
 

eibgrad

Part of the Furniture
Well at least it's configured to DROP packets unconditionally. But there are NO hits at the moment. Usually the hit count should match the hit count from the FORWARD chain's PControls rules. Not unless you rebooted.
 

Tech9

Part of the Furniture
How is Time Scheduling affected by NAT acceleration on/off? I remember @RMerlin explaining why it may not work with NAT acceleration enabled. I also remember seeing a note about it in GUI...? The problem is, this router doesn't have NAT acceleration on/off setting in GUI. It has to be disabled in SSH or by activating Traditional/Cake QoS.
 

TheLyppardMan

Very Senior Member
It occurred to me late last night that I may have had the test restrictions for the Android device disabled when I ran the second script, so I have just switched it back on (to be on all day) and this is the latest output:-

/jffs/scripts$ iptables -vnL PControls
Chain PControls (1 references)
pkts bytes target prot opt in out source destination
0 0 logdrop all -- br0 br0 0.0.0.0/0 0.0.0.0/0
27 1571 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
123 7890 NSFW all -- * * 0.0.0.0/0 0.0.0.0/0
123 7890 logdrop all -- * * 0.0.0.0/0
 

ColinTaylor

Part of the Furniture
Did you see my comment in post #7? It seems more than coincidental that you encounter this problem within hours of the clocks changing. Also, in the two tests you did you didn't wait more than one hour.
 

eibgrad

Part of the Furniture
It occurred to me late last night that I may have had the test restrictions for the Android device disabled when I ran the second script, so I have just switched it back on (to be on all day) and this is the latest output:-

/jffs/scripts$ iptables -vnL PControls
Chain PControls (1 references)
pkts bytes target prot opt in out source destination
0 0 logdrop all -- br0 br0 0.0.0.0/0 0.0.0.0/0
27 1571 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
123 7890 NSFW all -- * * 0.0.0.0/0 0.0.0.0/0
123 7890 logdrop all -- * * 0.0.0.0/0

Well the plot thickens. What's in that NSFW chain?

Code:
iptables -vnL NSFW
 

TheLyppardMan

Very Senior Member
Did you see my comment in post #7? It seems more than coincidental that you encounter this problem within hours of the clocks changing. Also, in the two tests you did you didn't wait more than one hour.
I checked the router was showing the correct time on Sunday morning and it was and is still showing the correct time. Why do I need to wait more than an hour?
 

TheLyppardMan

Very Senior Member
Here's the latest output from running the second script:-
/jffs/scripts$ iptables -vnL PControls
Chain PControls (1 references)
pkts bytes target prot opt in out source destination
0 0 logdrop all -- br0 br0 0.0.0.0/0 0.0.0.0/0
40 2247 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
5144 350K NSFW all -- * * 0.0.0.0/0 0.0.0.0/0
5144 350K logdrop all -- * * 0.0.0.0/0
 

eibgrad

Part of the Furniture
We need to see what's in NSFW, since it precedes the normal drop (or logdrop) of AIP.

Code:
iptables -vnL NSFW
 

ColinTaylor

Part of the Furniture
I checked the router was showing the correct time on Sunday morning and it was and is still showing the correct time. Why do I need to wait more than an hour?
Just to see whether or not it is related to the one hour clock change. If you still have the problem, say two hours later, then it's not connected to the clock change.

I tested the time blocking on my RT-AX86U and it works fine.
 

TheLyppardMan

Very Senior Member
We need to see what's in NSFW, since it precedes the normal drop (or logdrop) of AIP.

Code:
iptables -vnL NSFW
Here you go:-
/jffs/scripts$ iptables -vnL NSFW
Chain NSFW (2 references)
pkts bytes target prot opt in out source destination
0 0 DROP ah -- br0 ppp0 0.0.0.0/0 0.0.0.0/0
0 0 DROP esp -- br0 ppp0 0.0.0.0/0 0.0.0.0/0
3 87 DROP udp -- br0 ppp0 0.0.0.0/0 0.0.0.0/0 udp dpt:4500
3 87 DROP udp -- br0 ppp0 0.0.0.0/0 0.0.0.0/0 udp dpt:500
0 0 DROP udp -- br0 ppp0 0.0.0.0/0 0.0.0.0/0 udp dpt:1701
0 0 DROP 47 -- br0 ppp0 0.0.0.0/0 0.0.0.0/0
0 0 DROP tcp -- br0 ppp0 0.0.0.0/0
 

eibgrad

Part of the Furniture
Given everything in NSFW is DROPs, there's no means to bypass being blocked based on the FORWARD chain's call to PControls, or PControls's call to the NSFW chain. Everything appears correct and should be working.

Personally I believe @Tech9 was possibly on the right track concerning NAT acceleration (in all its forms; CTF, SFE, FA, etc.). These are essentially "hacks" and are known to break things (which is why I refuse to use them).
 

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