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: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 9: | Line 15: | ||
\\ | \\ | ||
- | The returned string might look something like: | + | 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 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 77: | Line 111: | ||
done | done | ||
</ | </ | ||
+ | |||
+ | \\ | ||
+ | |||
+ | If you have JFFS enabled in FreshTomato, | ||
+ | |||
+ | \\ | ||
+ | |||
+ | \\ | ||
===== Credits ===== | ===== Credits ===== | ||
- | [[http:// | + | [[http:// |