Internet Access Time Control Not Working

[David Wolfe]

I've been using the parental controls to keep my daughter on track for going to bed on time during the school week. I believe with 386.1 (may have happened before since my last update before this release was back in November of 2020) the Time Scheduling in AIProtection is no longer working reliably. I have tested this out on one of my own systems and can set an Internet off-time window but the workstation still has free roam to do anything it wants online. The Network Map device list shows the device with a - icon (Internet Access Blocked) but this is certainly NOT the case.

I thought maybe it was just not blocking existing app connections like Discord that's been on all evening but I can fire up a new app or web browser and still get access to the Internet during the off-time window.

I can set the device status in the Time Scheduling page to "Blocked" and it almost immediately blocks all connections so I believe the mechanism for blocking Internet access is working, it's just not enabling that block when it should be.

Anyone having similar issues and/or know of a solution? Having to remember to manually turn off the kid's access is a pain in the heiny.

Thanks!

 

[OzarkEdge]

I've been using the parental controls to keep my daughter on track for going to bed on time during the school week. I believe with 386.1 (may have happened before since my last update before this release was back in November of 2020) the Time Scheduling in AIProtection is no longer working reliably. I have tested this out on one of my own systems and can set an Internet off-time window but the workstation still has free roam to do anything it wants online. The Network Map device list shows the device with a - icon (Internet Access Blocked) but this is certainly NOT the case.

I thought maybe it was just not blocking existing app connections like Discord that's been on all evening but I can fire up a new app or web browser and still get access to the Internet during the off-time window.

I can set the device status in the Time Scheduling page to "Blocked" and it almost immediately blocks all connections so I believe the mechanism for blocking Internet access is working, it's just not enabling that block when it should be.

Anyone having similar issues and/or know of a solution? Having to remember to manually turn off the kid's access is a pain in the heiny.

Thanks!

If only wireless access, maybe a guest WLAN with restricted access time will work.

OE

 

[dave14305]

It’s fixed in the 386.2 alpha 1 build of Merlin.

 

[David Wolfe]

Thanks for the confirmation, Dave. At least I know I'm not crazy.

 

[David Wolfe]

Any major concerns with installing an alpha release of firmware? I've always stuck with the release versions but I'd like to get to a version where the time scheduling feature is functional.

 

[FelixGV]

My RT-AX86U had the same issue with 386.1. Today I tested 386.2 alpha 1 and I think it has been fixed.

 

[dave14305]

Any major concerns with installing an alpha release of firmware? I've always stuck with the release versions but I'd like to get to a version where the time scheduling feature is functional.

I'm not usually into alphas or betas either, but after reading what has been changed since 386.1, there wasn't anything "risky" in my opinion. There was no new code from ASUS to deal with, for example. Just Merlin updating certain packages and fixing some things to make his code look more like ASUS'. For me, 386.2 Alpha 1 is more like 386.1.1 (in my head).

 

[eibgrad]

Not sure how AIP implements time scheduling, but you could just use iptables to accomplish the same thing.

iptables -I FORWARD -m mac --mac-source 0a:32:13:75:7d:95 -m time --timestart 20:00 --timestop 00:00 --weekdays Sun,Mon,Tue,Wed,Thu --kerneltz -j REJECT
iptables -I FORWARD -m mac --mac-source 0a:32:13:75:7d:95 -m time --timestart 00:00 --timestop 08:00 --weekdays Mon,Tue,Wed,Thu,Fri --kerneltz -j REJECT

That is unless AIP is using this same technique and *it* has a problem.

If it works, at least it avoids having to deal w/ Alpha firmware.

P.S. The following link is pretty old, so keep that in mind. Things could be a lot different by now. But anything based on time scheduling using iptables has a tradition of being a bit complicated and full of gotchas.

Blocking Internet at specific times using Netfilter / iptables on OpenWrt Router

From the title, it should already be obvious that this will apply to a very specific case, but I'm sure there are parts of it that will be h...

whirlysworld.blogspot.com

 

[dave14305]

Not sure how AIP implements time scheduling, but you could just use iptables to accomplish the same thing.

iptables -I FORWARD -m mac --mac-source 0a:32:13:75:7d:95 -m time --timestart 20:00 --timestop 00:00 --weekdays Sun,Mon,Tue,Wed,Thu --kerneltz -j REJECT
iptables -I FORWARD -m mac --mac-source 0a:32:13:75:7d:95 -m time --timestart 00:00 --timestop  8:00 --weekdays Mon,Tue,Wed,Thu,Fri --kerneltz -j REJECT

That is unless AIP is using this same technique and *it* has a problem.

If it works, at least it avoids having to deal w/ Alpha firmware.

P.S. The following link is pretty old, so keep that in mind. Things could be a lot different by now. But anything based on time scheduling using iptables has a tradition of being a bit complicated and full of gotchas.

Blocking Internet at specific times using Netfilter / iptables on OpenWrt Router

From the title, it should already be obvious that this will apply to a very specific case, but I'm sure there are parts of it that will be h...

whirlysworld.blogspot.com

The issue in 386.1 is that the PControls chain is missing a final DROP statement (if logging is enabled it would be logdrop instead of DROP). So everything was passing through to the ACCEPT in the FORWARD chain for lan to wan traffic.

iptables -A PControls -j DROP
ip6tables -A PControls -j DROP

 

[dave14305]

I'm really procrastinating doing important things today, so this is a potential workaround for anyone not ready to try the alpha. This would go in /jffs/scripts/firewall-start (after any existing content if you run other firewall-related scripts):

#!/bin/sh

logdrop="$(nvram get fw_log_x)"

if [ "$logdrop" != "drop" ] && [ "$logdrop" != "both" ]; then
    logdrop="DROP"
else
    logdrop="logdrop"
fi

if ! iptables -C PControls -j $logdrop 2>/dev/null; then
    iptables -A PControls -j $logdrop
fi

if [ "$(nvram get ipv6_service)" != "disabled" ]; then
    if ! ip6tables -C PControls -j $logdrop 2>/dev/null; then
        ip6tables -A PControls -j $logdrop
    fi
fi

And I think it should be harmless once you do upgrade to 386.2 since it only adds the missing rule if it is not already present.