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 01:52] – Removed extraneous blank lines techie007 | ||
---|---|---|---|
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//, // |
- | <code -> | + | To see what's in the first rule, we can issue the following command at a FreshTomato shell prompt: |
- | nvram get rrule0 | + | <code ->nvram get rrule0</ |
- | </ | + | |
\\ | \\ | ||
- | The returned string might look something like: | + | The returned string might look something like this: |
- | + | <code -> | |
- | <code -> | + | |
- | 1|540|1140|62|||block-site.com$|0|New Rule 1 | + | |
- | </ | + | |
\\ | \\ | ||
- | 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: |
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | * 16 = Thursday | ||
+ | * 32 = Friday | ||
+ | * 64 = Sunday | ||
- | **Field 7:** This field contains | + | For multiple days, add the corresponding numbers for each day. |
- | **Field 8:** This field stores as a binary coded value if ActiveX, Flash or Java are to be blocked | + | In the above example, the fourth |
- | Now that we have a basic understanding about how Access Restriction rules work, we can write shell scripts to control the rules. | + | **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 99: | ||
</ | </ | ||
- | ===== Credits ===== | + | \\ |
- | [[http:// | + | If you have JFFS enabled |
+ | |||
+ | ===== Credits ===== | ||
+ | |||
+ | [[http:// |