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:47] – hogwild | access_restrictions [2023/07/02 16:23] – [Scripting Access Restrictions] -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 9: | Line 13: | ||
\\ | \\ | ||
- | The returned string might look something like: | + | The returned string might look something like this: |
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 17: | Line 23: | ||
\\ | \\ | ||
- | 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 540, 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 | + | Both the second and third fields will be -1 if you select |
- | **Field | + | **Field |
- | **Field 6:** This has the // | + | It is coded in binary: |
- | **Field 7:** | + | |
+ | | ||
+ | | ||
+ | | ||
+ | * 16 = Thursday | ||
+ | * 32 = Friday | ||
+ | * 64 = Sunday | ||
- | **Field 8:** This field stores as a binary coded value if ActiveX, Flash or Java are to be blocked | + | For multiple days, simply add together the corresponding numbers |
- | Now that we have a basic understanding about how Access Restriction rules work, we can write shell scripts to control the rules. | + | 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 6:** has the // | ||
+ | |||
+ | **Field 7:** contains the Domains/ | ||
+ | |||
+ | In the example above, domain names ending with " | ||
+ | |||
+ | **Field 8:** stores a binary coded value if ActiveX, Flash or Java are set to be blocked. | ||
+ | |||
+ | * A " | ||
+ | * A " | ||
+ | * A " | ||
+ | |||
+ | **Field 9:** stores the name that you gave to the rule being edited. | ||
+ | |||
+ | | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 78: | Line 110: | ||
</ | </ | ||
- | ===== Credits ===== | + | \\ |
- | [[http:// | + | If you have JFFS enabled |
+ | \\ | ||
+ | |||
+ | \\ | ||
+ | |||
+ | |||
+ | ===== Credits ===== | ||
+ | [[http:// |