This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
access_restrictions [2021/08/24 23:56] – hogwild | access_restrictions [2023/07/02 16:24] – -formatting hogwild | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Access Restrictions ====== | + | ====== |
- | Access Restriction rules are coded as strings separated by pipe ( | ) symbols. These are stored in NVRAM as variables named //rrule0//, //rrule1//, // | + | Access Restriction rules are coded as strings separated by pipe ( | ) symbols. These are stored in NVRAM as variables named //rrule0//, //rrule1//, // |
+ | |||
+ | \\ | ||
+ | |||
+ | To see what's in the first rule, we can issue the following command at a FreshTomato shell prompt: | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 10: | Line 16: | ||
The returned string might look something like this: | The returned string might look something like this: | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 17: | Line 25: | ||
\\ | \\ | ||
- | Let' | + | Let's look more closely |
**Field 1:** indicates whether the rule is currently enabled (1) or disabled (0). | **Field 1:** indicates whether the rule is currently enabled (1) or disabled (0). | ||
- | **Field 2:** specifies the start time, or time to start applying this rule, in minutes elapsed since midnight. In this case, start time is 5:40 AM, so the router should enforce this rule starting at 9:00 AM. | + | **Field 2:** specifies the start time, (time to start applying this rule), in minutes elapsed since midnight. |
- | **Field 3:** is the end time, or the time to stop applying | + | In this case, start time is 5:40 AM, so the router should enforce |
- | **Field | + | **Field |
- | For multiple days, add the corresponding numbers for each day. In the above example the fourth field is 62 which is equal to 2+4+8+16+32 . This means the rule should be active on Mon, Tue, Wed, Thu, and Fri. In other words, only on week days. If you had checked the option | + | Both the second and third fields will be -1 if you select the //‘All Day’// option in the Access Restrictions menu. |
+ | |||
+ | **Field 4:** specifies on which days the rule will be applied. | ||
+ | |||
+ | It is coded in binary: | ||
+ | |||
+ | * 1 = Sunday | ||
+ | * 2 = Monday | ||
+ | * 4 = Tuesday | ||
+ | * 8 = Wednesday | ||
+ | * 16 = Thursday | ||
+ | * 32 = Friday | ||
+ | * 64 = Sunday | ||
+ | |||
+ | For multiple days, simply | ||
+ | |||
+ | In the above example, the fourth field is 62, which is equal to 2 + 4 + 8 + 16 + 32 . This means the rule should be active on Mon, Tue, Wed, Thu, and Fri. That is, only on weekdays. If you had checked the // | ||
**Field 5:** shows the IP or MAC Address range on your network for which the rule should be applied. | **Field 5:** shows the IP or MAC Address range on your network for which the rule should be applied. | ||
- | **Field 6:** has the // | + | **Field 6:** has the // |
- | **Field 7:** contains the Domains/ | + | **Field 7:** contains the Domains/ |
- | **Field 8:** stores as a binary coded value if ActiveX, Flash or Java are to be blocked. 1 will block ActiveX, 2 will block Flash and 4 will block Java. | + | In the example above, domain names ending with " |
- | **Field | + | **Field |
- | | + | * A " |
+ | * A " | ||
+ | * A " | ||
+ | |||
+ | **Field 9:** stores the name that you gave to the rule being edited. | ||
+ | |||
+ | \\ Now that we have a basic sense of how Access Restriction rules work, we can write shell scripts to control the rules. | ||
\\ | \\ | ||
Line 81: | Line 111: | ||
done | done | ||
</ | </ | ||
+ | |||
+ | \\ | ||
+ | |||
+ | If you have JFFS enabled in FreshTomato, | ||
+ | |||
+ | \\ | ||
+ | |||
+ | \\ | ||
===== Credits ===== | ===== Credits ===== | ||
- | [[http:// | + | [[http:// |