Skip to content

gargoyle-firewall-util: fix weekly-range restriction rules never loading - #155

Merged
ispyisail merged 1 commit into
masterfrom
fix/nft-weekly-ranges-loading
Aug 1, 2026
Merged

gargoyle-firewall-util: fix weekly-range restriction rules never loading#155
ispyisail merged 1 commit into
masterfrom
fix/nft-weekly-ranges-loading

Conversation

@ispyisail

Copy link
Copy Markdown
Owner

Summary

  • Two independent bugs in make_nftables_rules.c meant every restriction/whitelist rule using the "weekly" schedule type (the general Restrictions form's own long-existing option, not just the Family Time wizard) silently failed to load into nftables — enabled in UCI, no error surfaced anywhere, just never enforced.
  • timerange weekly-ranges → the nft timerange extension's own grammar (command-line parser and its own display output) is weeklyranges, one word.
  • Even with the keyword fixed, a standalone space-surrounded - token in the value (the canonical Day HH:MM - Day HH:MM display format weekly_i18n() needs to correctly localize day names) gets misread by nft's own CLI as an attempted option flag.
  • Fixed by sanitizing a copy of the value (collapsing - to -, reusing the dynamic_replace loop idiom already established in restore_quotas.c for the same class of problem) before it reaches the nft command line, and correcting the keyword — the display format itself is unchanged.

Test plan

  • Scoped compile: make package/gargoyle-firewall-util/{clean,prepare,compile} — clean, no new warnings
  • Verified live on real hardware (GL-MT6000): hand-constructed the exact nft command the fixed binary produces, confirmed it loads; confirmed the old binary reproducibly fails with the exact syntax error seen in the wild
  • vnet phase 65 (new): real end-to-end packet test — a weekly-range rule covering the router's current day/time genuinely blocks a client's traffic, the identical rule shifted off-window genuinely allows it. All 3 checks pass.

…ables

Two independent bugs in how active_weekly_ranges gets turned into an nft
command, both dating to the original nftables rewrite -- affects every
restriction/whitelist rule using the weekly schedule type in the general
Restrictions form, not just the Family Time wizard.

1. The generated command used the keyword weekly-ranges (hyphenated).
   The nft timerange extensions own grammar (both its command-line parser
   and its own display output) uses weeklyranges, one word -- verified
   against netfilter-match-modules/nftables/timerange/libnftnl/
   src_expr_timerange.c. Every weekly-range rule failed to load with
   syntax error, options must be specified before commands, silently:
   the rule stays enabled in UCI, just never actually enforces anything.

2. Independently, even with the keyword fixed, a standalone space-
   surrounded - token in the value (e.g. Day HH:MM - Day HH:MM, the
   canonical display format weekly_i18n() in restrictions.js needs to
   correctly localize day names) gets misread by nfts own CLI as an
   attempted option flag, hitting the identical error. Confirmed live
   against nft 1.1.6 by isolating each half: a well-formed value still
   failed until the spacing around the hyphen was collapsed.

Fixed by sanitizing a copy of the value (collapsing  -  to -, reusing
the dynamic_replace loop idiom already established in restore_quotas.c
for the same class of problem) before it reaches the nft command line,
and correcting the keyword -- the display format itself is unchanged, so
weekly_i18n() keeps working. Verified end to end against the real
compiled binary on a live router: a correctly-scheduled weekly-range
rule now loads and is confirmed present in the live ruleset with the
right decoded time values.
@ispyisail
ispyisail merged commit 3ae7722 into master Aug 1, 2026
1 check passed
@ispyisail
ispyisail deleted the fix/nft-weekly-ranges-loading branch August 1, 2026 13:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant