Ai Protection Parental Time Control not working properly

[TheLyppardMan]

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]

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.

iptables -vnL FORWARD

 

[TheLyppardMan]

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.

 

[eibgrad]

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).

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.

iptables -vnL PControls

 

[john9527]

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]

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.

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.

 

[ColinTaylor]

@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]

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).

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.

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.

 

[TheLyppardMan]

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]

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]

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]

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]

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]

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?

iptables -vnL NSFW

 

[TheLyppardMan]

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]

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]

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

iptables -vnL NSFW

 

[ColinTaylor]

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]

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

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]

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).