What's new

AC68U - Time Schedule

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Brokk

Occasional Visitor
New school year is starting. Last night I was using the Asus app to update the scheduler for both my kids and the family TV. Suddenly, things just went whacky and the router stopped allowing internet traffic through for any device. I stayed up for two hours trying to troubleshoot before going to bed at 1am. Back up at 6am and started again. When I finally realized the Asus router was just not working properly, I updated the firmware, that didn't fix it, then a factory reset. That fixed the problem. I restored my settings from a backup (that's why we have them right?) and it went back to being broken. So I did another factory reset, and started the long process of applying them by hand.

The one feature of this router I use more than anything else is the time scheduling for my kids. It's been rock solid for years on that front. Now, it's completely fritzy. It will work for a while, then shut off one kid (all of their devices) in the middle of the day, while the other one works fine most of the time, but it will kick him on/off randomly for a few min here and there. I've never seen it act this way.

Old FW (I downloaded from Asus and installed manually): 3.0.0.4.38218881
New FW the router installed itself: 3.0.0.4.384_45717-gadd52a8

Yes, NAT acceleration is off.

This is what the system log says when I toggle the time scheduler on/off for a device
Sep 3 13:57:45 rc_service: httpds 190:notify_rc restart_firewall
Sep 3 13:57:46 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Sep 3 13:58:09 rc_service: httpds 190:notify_rc restart_firewall
Sep 3 13:58:10 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)

So what advice is there for me? I'm seriously tempted to restore the prior FW, factory reset, then reapply all my changes. After all, I've lost most of the day to this already. I'm hoping there is a more reasonable solution.
 
Time scheduling will be based (clearly) on time of day and IP address of the devices being restricted. So first step is to make sure your router is keeping proper time and has the proper timezone. Should be easy enough to confirm on your Syslog page.

You also need to confirm the IP addresses are the actual IP addresses and not changing unintentionally via DHCP. The config is also done based on MAC address, so I'm not certain how the underlying iptables rules update if an assigned IP changes for a device.

If you setup your rules and run this command in an SSH terminal to the router, we might see something technical you don't.
Code:
iptables -S | grep PControls
iptables -t nat -S PCREDIRECT
You might also share your Time Scheduling config by running this command and sharing the output:
Code:
nvram show 2>/dev/null | grep ^MULTIFILTER
And your timezone and current date/time:
Code:
cat /etc/TZ
date
There was also a similarly frustrating thread a while back that didn't really get resolved, but it's worth a read.
Issues with Time Scheduling...

EDIT: fixed the iptables command to include all lines that reference PControls, including the FORWARD chain.
 
Last edited:
There was also a similarly frustrating thread a while back that didn't really get resolved, but it's worth a read.
Issues with Time Scheduling...

I read through that thread. The SSH stuff kind of lost me, then I went down a rabbit hole trying to figure out how to get an SSH client working on my PC, eventually I put it aside as too time consuming a path at the moment. I can revisit it this evening. The resolution of that thread at the end came back around to NAT acceleration. It was actually turned on, when he had originally claimed it was off. Once he played with that it fixed the issue.

I'm familiar with DHCP and MAC Addresses. I had a number of my client IPs setup as static, but I think that was just to make it easier for me to trouble shoot logs when I had a difficult long term guest staying with us for a while. Of course all of that got lost with the factory reset.

The System Log is showing the correct time. The test case is a spare phone. While I haven't specifically mapped the IP to make sure it's not changing from one minute to the next (as I toggle the time scheduling on/off), it seems unlikely to cause this issue.

I will dig in and see about getting an SSH client working to get that information for you. Thanks for taking a look.
 
If you setup your rules and run this command in an SSH terminal to the router, we might see something technical you don't.
Code:
iptables -S | grep PControls
iptables -t nat -S PCREDIRECT
You might also share your Time Scheduling config by running this command and sharing the output:
Code:
nvram show 2>/dev/null | grep ^MULTIFILTER
And your timezone and current date/time:
Code:
cat /etc/TZ
date

brokk@RT-AC68U:/tmp/home/root# iptables -S PControls
-N PControls
-A PControls -i br0 -o br0 -j ACCEPT
-A PControls -m state --state INVALID -j DROP
-A PControls -j ACCEPT
brokk@RT-AC68U:/tmp/home/root# iptables -t nat -S PCREDIRECT
-N PCREDIRECT
-A PCREDIRECT -i br0 -m time --weekdays Sun --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j ACCEPT
-A PCREDIRECT -i br0 -m time --weekdays Mon --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j ACCEPT
-A PCREDIRECT -i br0 -m time --timestart 05:00:00 --timestop 21:00:00 --weekdays Tue --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j ACCEPT
-A PCREDIRECT -i br0 -m time --weekdays Wed --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j ACCEPT
-A PCREDIRECT -i br0 -m time --weekdays Thu,Fri,Sat --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j ACCEPT
-A PCREDIRECT ! -d 192.168.1.0/24 -i br0 -p tcp -m tcp --dport 80 -m mac --mac-source 78:54:2E:0E:56:59 -j DNAT --to-destination 192.168.1.1:18099
brokk@RT-AC68U:/tmp/home/root# nvram show 2>/dev/null | grep ^MULTIFILTER
MULTIFILTER_URL_ENABLE=
MULTIFILTER_ALL=1
MULTIFILTER_MACFILTER_DAYTIME=>>>T<000522<T<110522<T<220522<T<330522<T<440522<T<550523<T<660523>T<000521<T<110506<T<110721<T<220506<T<220721<T<330506<T<330721<T<440506<T<440721<T<550506<T<550722<T<660522>T<000521<T<110506<T<110721<T<220506<T<220721<T<330506<T<330721<T<440506<T<440721<T<550506<T<550722<T<660522>T<020000<T<220521<T<300000
MULTIFILTER_TMP=
MULTIFILTER_DEVICENAME=Samsung TV>Receiver in Family Room>Samsung BluRay>T>T>T>T
MULTIFILTER_ENABLE=2>2>2>1>0>0>1
MULTIFILTER_MAC=7C:64:56:59:E4:74>A8:54:B2:A9:17:32>CC:B1:1A:93:FF:3B>78:54:2E:0E:56:59>4C:CC:6A:88:59:2E>6C:40:08:78:4A:EE>64:A2:F9:EF:63:C7
MULTIFILTER_URL=
brokk@RT-AC68U:/tmp/home/root# cat /etc/TZ
EST5DST,M3.2.0/2,M10.2.0/2
brokk@RT-AC68U:/tmp/home/root# date
Tue Sep 3 19:26:40 DST 2019
brokk@RT-AC68U:/tmp/home/root#


If "--mac-source 78:54:2E:0E:56:59" is supposed to be a client MAC address, I can honestly say that is currently not one of my clients.
 
Last edited:
If "--mac-source 78:54:2E:0E:56:59" is supposed to be a client MAC address, I can honestly say that is currently not one of my clients.
That MAC is from a DLink device. Does it ring a bell?

I also amended my previous post to get more of the iptables rules:
Code:
iptables -S | grep PControls
 
Also just an example of the iptables rules I see depending on which "action" I choose from the dropdown in the Time Scheduling client list (Block, Time, Disable).
Code:
Block
-A FORWARD -i br0 -m mac --mac-source D0:D2:B0:DD:DD:DD -j DROP

Time with no schedule defined yet
-A FORWARD -s 192.168.1.86/32 -i br0 -j DROP

Time with schedule defined (allow 8a-5p every day)
-A FORWARD -s 192.168.1.86/32 -i br0 -m time --timestart 08:00:00 --timestop 17:00:00 --weekdays Sun --kerneltz -j PControls
-A FORWARD -s 192.168.1.86/32 -i br0 -m time --timestart 08:00:00 --timestop 17:00:00 --weekdays Mon --kerneltz -j PControls
-A FORWARD -s 192.168.1.86/32 -i br0 -m time --timestart 08:00:00 --timestop 17:00:00 --weekdays Tue --kerneltz -j PControls
-A FORWARD -s 192.168.1.86/32 -i br0 -m time --timestart 08:00:00 --timestop 17:00:00 --weekdays Wed --kerneltz -j PControls
-A FORWARD -s 192.168.1.86/32 -i br0 -m time --timestart 08:00:00 --timestop 17:00:00 --weekdays Thu --kerneltz -j PControls
-A FORWARD -s 192.168.1.86/32 -i br0 -m time --timestart 08:00:00 --timestop 17:00:00 --weekdays Fri --kerneltz -j PControls
-A FORWARD -s 192.168.1.86/32 -i br0 -m time --timestart 08:00:00 --timestop 17:00:00 --weekdays Sat --kerneltz -j PControls
-A FORWARD -s 192.168.1.86/32 -i br0 -j DROP
Disable removed any rules from being in effect for that client.
 
brokk@RT-AC68U:/tmp/home/root# iptables -S | grep PControls
-N PControls
-A FORWARD -i br0 -m time --weekdays Sun --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j PControls
-A FORWARD -i br0 -m time --weekdays Mon --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j PControls
-A FORWARD -i br0 -m time --timestart 05:00:00 --timestop 21:00:00 --weekdays Tue --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j PControls
-A FORWARD -i br0 -m time --timestart 05:00:00 --timestop 23:59:59 --weekdays Wed --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j PControls
-A FORWARD -i br0 -m time --weekdays Thu,Fri,Sat --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j PControls
-A FORWARD -s 192.168.1.187/32 -i br0 -m time --weekdays Sun --kerneltz -j PControls
-A FORWARD -s 192.168.1.187/32 -i br0 -m time --weekdays Mon --kerneltz -j PControls
-A FORWARD -s 192.168.1.187/32 -i br0 -m time --timestart 05:00:00 --timestop 21:00:00 --weekdays Tue --kerneltz -j PControls
-A FORWARD -s 192.168.1.187/32 -i br0 -m time --timestart 05:00:00 --timestop 23:59:59 --weekdays Wed --kerneltz -j PControls
-A FORWARD -s 192.168.1.187/32 -i br0 -m time --weekdays Thu,Fri,Sat --kerneltz -j PControls
-A PControls -i br0 -o br0 -j ACCEPT
-A PControls -m state --state INVALID -j DROP
-A PControls -j ACCEPT
brokk@RT-AC68U:/tmp/home/root#
 
That MAC is from a DLink device. Does it ring a bell?
Code:
iptables -S | grep PControls

Occasionally a device called DLink pops up in my client list. Until now I just assumed it was one of my Velop nodes. Normally they are called LinkSys, but we have one that is a little off. Otherwise... no clue.

Can an ethernet hub show up as a device? I have a 4-way setup to help out with the Velop setup. I didn't think it would show up as a client though...

In any case, there is no way I would be assigning it a time schedule.

Ha! I found it. It's my media PC in the family room. I just hadn't turned it on recently.
 
Looking at the IPs in that output, it doesn't make sense. Things are missing. Some IPs are being assigned the wrong times. I think I'm going to have to go back to preventing to IPs from changing so I can make better sense of all this.
 
OK, let's focus on just one for now to see if this makes sense.

Capture.JPG


Media-PC 78:54:2E:0E:56:59 192.168.1.157

-A FORWARD -i br0 -m time --weekdays Sun --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j PControls
-A FORWARD -i br0 -m time --weekdays Mon --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j PControls
-A FORWARD -i br0 -m time --timestart 05:00:00 --timestop 21:00:00 --weekdays Tue --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j PControls
-A FORWARD -i br0 -m time --timestart 05:00:00 --timestop 23:59:59 --weekdays Wed --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j PControls
-A FORWARD -i br0 -m time --weekdays Thu,Fri,Sat --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j PControls

-A PCREDIRECT -i br0 -m time --weekdays Sun --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j ACCEPT
-A PCREDIRECT -i br0 -m time --weekdays Mon --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j ACCEPT
-A PCREDIRECT -i br0 -m time --timestart 05:00:00 --timestop 21:00:00 --weekdays Tue --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j ACCEPT
-A PCREDIRECT -i br0 -m time --timestart 05:00:00 --timestop 23:59:59 --weekdays Wed --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j ACCEPT
-A PCREDIRECT -i br0 -m time --weekdays Thu,Fri,Sat --kerneltz -m mac --mac-source 78:54:2E:0E:56:59 -j ACCEPT

If I'm reading that right, it should allow internet Sun, Mon, Thu, Fri, Sat. Tue 5am -> 9pm, Wed 5am -> 11:59pm. Correct?

As you can see from the image, that doesn't vaguely match what should be done for that device. Secondly, that schedule is what I have setup for my daughter's devices, which are not listed by Mac ID or by IP anywhere in the tables. Thirdly, her devices were restricted this morning after 5am. That doesn't match what is in the GUI, or the IP tables.

Yesterday (for her devices) the system broke at noon and wouldn't allow access. It specifically stated devices were not allowed at that time. It stayed broken through the early afternoon as I researched it. In the evening, it seemed to be working fine (allowing access), even though I hadn't changed anything. At 9pm on the nose, it worked perfectly and shut off access (--timestop 21:00:00), even though her devices aren't listed in the IP table.

Suggestions?

The kids are off to school this morning, so now is a good time to roll back to a previous FW version and factory reset...
 
If I'm reading that right, it should allow internet Sun, Mon, Thu, Fri, Sat. Tue 5am -> 9pm, Wed 5am -> 11:59pm. Correct?
Correct.
The kids are off to school this morning, so now is a good time to roll back to a previous FW version and factory reset...
I would at least go with a factory reset on the latest firmware. I'm running the Merlin firmware 384.13 which is based on 45717 and the behavior is predictable for me. I still don't understand why my rules use IP addresses and yours show MAC addresses.

You might try just erasing the settings for Time Scheduling (with the caveat that you're prepared to factory reset anyway) and see what happens if you start from scratch.
Code:
nvram set MULTIFILTER_URL_ENABLE=""
nvram set MULTIFILTER_ALL=0
nvram set MULTIFILTER_MACFILTER_DAYTIME=""
nvram set MULTIFILTER_TMP=""
nvram set MULTIFILTER_DEVICENAME=""
nvram set MULTIFILTER_ENABLE=""
nvram set MULTIFILTER_MAC=""
nvram set MULTIFILTER_URL=""
nvram commit
service restart_firewall
 
Occasionally a device called DLink pops up in my client list. Until now I just assumed it was one of my Velop nodes. Normally they are called LinkSys, but we have one that is a little off. Otherwise... no clue.

Can an ethernet hub show up as a device? I have a 4-way setup to help out with the Velop setup. I didn't think it would show up as a client though...
I forgot that I had read this earlier. What is the setup of your network, meaning where to clients connect -- to the Asus WiFi SSIDs or the Velop Mesh SSID? And how does the mesh and hub connect to the Asus? You may not be seeing the clients properly if they come through another device.
 
I forgot that I had read this earlier. What is the setup of your network, meaning where to clients connect -- to the Asus WiFi SSIDs or the Velop Mesh SSID? And how does the mesh and hub connect to the Asus? You may not be seeing the clients properly if they come through another device.

Verizon FIOS Ethernet -> Asus -> Main Velop Node -> hub -> Three other Velop nodes

Velop mesh handles all the wifi. Asus has wifi shut off (toggle switch on physical router). Asus handles all the DHCP and rules/scheduling. Asus has a HP Laserjet attached for network printing.

There used to be a Verizon router between the FIOS and Asus, but something about the setup stopped working a few weeks ago, so I pulled that hardware out of the setup. It was just a dumb pass through at that point. It went back to working fine afterward.

One weird thing is the network statistics. I thought after the factory reset, the statistics would be cleared out, but they still seemed available for the client devices. I wonder where that information is being cached.
 
I still don't understand why my rules use IP addresses and yours show MAC addresses.

If the device is actively on the network and has an IP address, then it uses IP. Once it's off the network long enough, it no longer has an IP associated with it and it uses the Mac. I puzzled over that last night until I realized the pattern
 
Baby steps.

I used your script to clear things out. I did a factory reset through the GUI, and it was instantly done. That didn't seem right. So I rebooted the router and it let me log in with my old credentials. That's definitely not right. So I did a hardware reset. When it finished, I unplugged it for a few minutes and plugged it back in to boot up again. I did a quick setup of the basics, turned off NAT acceleration and turned on SSH and ran the commands to see the IP table. Nice and clean.

I've started adding in a couple scheduler items and checking the IP table. So far the two are in sync. Hopefully this also resolves the random lockouts.
 
Baby steps.

I used your script to clear things out. I did a factory reset through the GUI, and it was instantly done. That didn't seem right. So I rebooted the router and it let me log in with my old credentials. That's definitely not right. So I did a hardware reset. When it finished, I unplugged it for a few minutes and plugged it back in to boot up again. I did a quick setup of the basics, turned off NAT acceleration and turned on SSH and ran the commands to see the IP table. Nice and clean.

I've started adding in a couple scheduler items and checking the IP table. So far the two are in sync. Hopefully this also resolves the random lockouts.
Make sure there are no browser ad-blockers that may be interfering with the router webpages. Let us know how it goes.
 
I'm going to just focus on the Scheduler stuff for now. I know the minimal setup recommends holding off on everything else until you make sure things are shaken out properly first.

What are your thoughts on the Analyzer settings? Are they worth turning back on eventually? I kind of like being able to look at a history of my kids web pages browses, but honestly the information gets a bit lost with so much traffic in the background. The router captures *everything*.
 
Make sure there are no browser ad-blockers that may be interfering with the router webpages. Let us know how it goes.

I don't use ad-blockers.

So far it seems to be working. No random lock outs. This evening it will get a more thorough testing when the kids start using the internet. I'll hold off making any other changes for a couple days (aside from the scheduler)

(update) So far so good. Evening and following morning went well with everything executing on time. I will now map out the rest of the week.

Ugh... New FW version available: 384_81049. I *just* got things working... (sigh) I honestly don't want to apply it. It is probably sensible to at least wait a few weeks for other people to discover/report new bugs. Right?
 
Last edited:
It's been almost a week and everything is still working fine. Seems like that was the solution.
 

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