Missmatch/bug found in Parental Control code.
Hi!
Here is a case and workaround for when parental control is malfunctioning. I’m running a Asus RT-AC66U with
Asuswrt-Merlin - build 3.0.0.4.374.34_2 (30-Oct-2013). I’ve had my Asus for a month now and tried the factory firmware and the two latest Merlin builds.
The Parental Control always works fine for one device. But if several devices are used and one of them is denied access all the time then there are problems.
I did some code review on pc.c and www/fullcalendar.js. And did some tests and found that the following nvram variables are important:
MULTIFILTER_MAC=xx:xx:xx:xx:xx:xx>yy:yy:yy:yy:yy:yy>zz:zz:zz:zz:zz:zz
MULTIFILTER_MACFILTER_DAYTIME=NoTitle<000102>NoTitle<000102>NoTitle<002021<NoTitle<112021<NoTitle<222021<NoTitle<332021<NoTitle<442021<NoTitle<552021<NoTitle<662021
MULTIFILTER_DEVICENAME=device1>device2>device3
MULTIFILTER_ENABLE=1>1>1
The implementation of pc.c relies completely on that the above nvram variables/lists are sorted in the same way. Position 1 in all lists should always be referring to device1/xx:xx..., position 2 to device2/yy:yy... and so on. All entries related to a specific device are separated with > (ascii 62). Individual daytime rules for the same device are separated with < (ascii 60) if more than one rule is defined.
E.g.: xx:xx:xx:xx:xx:xx has the first position in MULTIFILTER_MAC. The filter for that MAC is enabled since the first entry in MULTIFILTER_ENABLE equals 1 (enabled). And the time rule for that MAC is the first entry "NoTitle<000102” meaning MAC xx is allowed day 00, start at hour 01, ends at hour 02. All other times it is denied access.
One problem with the current implementation is that when a device is denied the whole week 24/7, which is the default setting in the GUI, it doesn’t get an entry in the MULTIFILTER_MACFILTER_DAYTIME at all, not even an empty entry. Then the number of entries will not match with the other lists. pc.c will index itself wrong in the lists from the first missing daytime rule, the missing MAC will get the daytime rule for the next MAC and so on. I.e. all devices after the missing device will get wrong daytime rules.
Workaround: always have at least one one-hour ”allow” entry for all devices that shall be controlled by parental control, then it will work.
It would be good if Asus could fix this. But I don't know how to reach them. The fix should probably be done in www/fullcalendar.js which seems to build the MULTIFILTER_MACFILTER_DAYTIME list. I think it should always insert an empty daytime rule for all devices that otherwise should be missing.
Testcase, use 2 devices:
Action 1:
MAC1: xx:xx:xx:xx:xx:xx, deny all the time, 24/7.
MAC2: yy:yy:yy:yy:yy:yy allow all the time.
Apply the rules from the GUI.
Unwanted result: MAC1 will be allowed all the time, and MAC2 will be denied all the time!
Resulting rules can be viewed in /tmp/filter_rules on the asus.
/masseth
Hi!
Here is a case and workaround for when parental control is malfunctioning. I’m running a Asus RT-AC66U with
Asuswrt-Merlin - build 3.0.0.4.374.34_2 (30-Oct-2013). I’ve had my Asus for a month now and tried the factory firmware and the two latest Merlin builds.
The Parental Control always works fine for one device. But if several devices are used and one of them is denied access all the time then there are problems.
I did some code review on pc.c and www/fullcalendar.js. And did some tests and found that the following nvram variables are important:
MULTIFILTER_MAC=xx:xx:xx:xx:xx:xx>yy:yy:yy:yy:yy:yy>zz:zz:zz:zz:zz:zz
MULTIFILTER_MACFILTER_DAYTIME=NoTitle<000102>NoTitle<000102>NoTitle<002021<NoTitle<112021<NoTitle<222021<NoTitle<332021<NoTitle<442021<NoTitle<552021<NoTitle<662021
MULTIFILTER_DEVICENAME=device1>device2>device3
MULTIFILTER_ENABLE=1>1>1
The implementation of pc.c relies completely on that the above nvram variables/lists are sorted in the same way. Position 1 in all lists should always be referring to device1/xx:xx..., position 2 to device2/yy:yy... and so on. All entries related to a specific device are separated with > (ascii 62). Individual daytime rules for the same device are separated with < (ascii 60) if more than one rule is defined.
E.g.: xx:xx:xx:xx:xx:xx has the first position in MULTIFILTER_MAC. The filter for that MAC is enabled since the first entry in MULTIFILTER_ENABLE equals 1 (enabled). And the time rule for that MAC is the first entry "NoTitle<000102” meaning MAC xx is allowed day 00, start at hour 01, ends at hour 02. All other times it is denied access.
One problem with the current implementation is that when a device is denied the whole week 24/7, which is the default setting in the GUI, it doesn’t get an entry in the MULTIFILTER_MACFILTER_DAYTIME at all, not even an empty entry. Then the number of entries will not match with the other lists. pc.c will index itself wrong in the lists from the first missing daytime rule, the missing MAC will get the daytime rule for the next MAC and so on. I.e. all devices after the missing device will get wrong daytime rules.
Workaround: always have at least one one-hour ”allow” entry for all devices that shall be controlled by parental control, then it will work.
It would be good if Asus could fix this. But I don't know how to reach them. The fix should probably be done in www/fullcalendar.js which seems to build the MULTIFILTER_MACFILTER_DAYTIME list. I think it should always insert an empty daytime rule for all devices that otherwise should be missing.
Testcase, use 2 devices:
Action 1:
MAC1: xx:xx:xx:xx:xx:xx, deny all the time, 24/7.
MAC2: yy:yy:yy:yy:yy:yy allow all the time.
Apply the rules from the GUI.
Unwanted result: MAC1 will be allowed all the time, and MAC2 will be denied all the time!
Resulting rules can be viewed in /tmp/filter_rules on the asus.
/masseth
Last edited: