luci-app-fwlive: add firewall live view

[lucas-albers-lz4]

Summary

Add luci-app-fwlive (Firewall Live View): a Status menu view that polls
firewall-only log lines via a dedicated rpcd plugin (rules, poll,
resolve, logging_status, enable_wan_logging, disable_wan_logging).

License: Apache-2.0 (PKG_LICENSE). This PR is a snapshot of
https://github.com/lucas-albers-lz4/fwlive (signed binary feed remains for
non-snapshot users), not a move.

Maintenance

fwlive stays the development home. This tree is a snapshot. On conflict, the
next snapshot from that repository replaces this copy — land fixes there
first. A PKG_SOURCE tarball was considered and declined: LuCI applications
are in-tree under applications/, and Weblate owns po/<lang>/ after merge.

Design notes

• Sessions never get ubus log.read. The plugin filters logs as root
  under a narrow ACL (read/write scopes kept separate).
• WAN log=1 is opt-in from the UI; prerm restores the saved baseline
  (fail-open).
• First commit ships po/templates only. Locales can come from Weblate
  after merge. Please do not hand-add .po files in follow-ups that would
  clobber Weblate.
• PKG_VERSION / PKG_RELEASE kept in lockstep with the out-of-tree app.
• Generated shell/JS snapshots come from the fwlive monorepo generators;
  Node/core/ are not vendored here.
• Depends: luci-base, logd, jsonfilter. Optional hostnames use
  BusyBox nslookup (stock image).

Review follow-up (second commit)

Addresses the first-round findings: rules map assembled in the current shell
(nft/iptables labels reach the client); reverse DNS via nslookup;
jsonfilter declared and no longer a silent empty table; poll classifier is
one awk pass; json_escape is self-contained for prerm; UCI names with
whitespace are not word-split.

Test plan

• Build luci-app-fwlive against a current OpenWrt SDK / image builder
• Install; confirm Status → Firewall Live View menu appears
• With fw4/nft, confirm rules with log prefix / !fw4: comments show labels
• Poll updates; busy WAN-logging does not stall the 1s interval
• Opt-in WAN logging; confirm events; disable / uninstall restores baseline
• Confirm session ACL cannot call log.read directly
• Show hostnames: a PTR-backed IP resolves on a stock image (no extra pkgs)

[openwrt-ai]

Reviewed 1 new commit (91b4629). The commit message matches the diff; no commit-level issues.

Two of the inline findings look like they break advertised features on a stock image rather than being polish: the rules map is assembled inside pipeline subshells so the nft/iptables log-prefix labels never reach the client (the __rulesmap_iptables selftest uses a redirect and so passes), and resolve calls getent, which is not present anywhere in OpenWrt. Worth confirming both against a real device before merge, since the current code fails silently in each case.

---

Generated by Claude Code

[openwrt-ai]

map_from_nft_stream runs as the right-hand side of a pipeline, so in POSIX sh (BusyBox ash / dash — this file is #!/bin/sh) it executes in a subshell. Every map_add it performs updates a copy of OUT, which is discarded when the subshell exits. By the time line 229 prints the result, OUT still holds only what map_uci_rule_names added — none of the nft log prefix / comment "!fw4: ..." mappings ever reach the client. Same for the iptables-save / ip6tables-save pipelines on lines 222 and 224.

Verified with dash:

$ OUT=''; add(){ OUT="${OUT}${OUT:+,}$1"; }; stream(){ while IFS= read -r l; do add "$l"; done; }
$ printf 'a\nb\n' | stream ; echo "[$OUT]"
[]
$ printf 'a\nb\n' > in ; stream < in ; echo "[$OUT]"
[a,b]

Note the selftest path does not hit this: rulesmap_from_iptables_file feeds the same function via a redirect (map_from_iptables_save_stream < "$file"), which stays in the current shell — so __rulesmap_iptables passes while the production path silently returns an almost-empty rules map.

Fix by feeding the stream functions through a redirect rather than a pipe (spool the nft list ruleset / iptables-save output to a temp file first, or have the stream functions emit fragments on stdout and accumulate with command substitution). Deliberate use of the pipeline subshell elsewhere (fwlive-log-filter.sh keeps sep local that way) makes this one look accidental rather than intended.

---

Generated by Claude Code

[openwrt-ai]

getent does not exist on a stock OpenWrt image, so resolve can never return a name and the "show hostnames" feature is permanently dead:

• musl ships no getent (it is a glibc/NSS utility), and OpenWrt's glibc runtime package installs only ldd — see package/libs/toolchain/Makefile;
• BusyBox has no getent applet (nothing in package/utils/busybox/config/ declares one);
• a full-tree grep of openwrt/openwrt at 93cf01b and of openwrt/packages at master finds no package providing getent and no in-tree script that calls it.

run_with_timeout swallows the command not found, line comes back empty, resolve_hostname returns 1, and the method answers {"names":{}} on every call — indistinguishable from "no PTR record", so the client's hostnameFailed TTL cache just retries forever.

Please either switch to a tool that exists on the target (BusyBox nslookup <ip> does reverse lookups) or, if getent is genuinely intended, add the providing package to LUCI_DEPENDS in the Makefile and name it in the README's Dependencies section. A command -v probe surfaced through logging_status/blockers would also stop the UI from offering a toggle that cannot work.

---

Generated by Claude Code

[openwrt-ai]

The clamp is bypassable with an over-long digit string. case "$first" in ''|*[!0-9]*) on line 265 accepts any number of digits, and test -gt then overflows instead of comparing — the 2>/dev/null hides the diagnostic and the failing test takes the else branch, leaving lines unclamped for the JSON interpolation on line 274:

$ dash -c 'lines=99999999999999999999; if [ "$lines" -gt 2000 ] 2>/dev/null; then echo clamp; else echo "NOCLAMP lines=$lines"; fi'
NOCLAMP lines=99999999999999999999

A read-ACL session can therefore drive ubus call log read '{"lines":<huge>}'. ({"addresses":["0"]} is also accepted and forwards "lines":0, which is not a value the caller can mean.) Rejecting anything longer than POLL_LINES_MAX before the numeric comparison closes both:

Suggested change

	if [ "$lines" -gt "$POLL_LINES_MAX" ] 2>/dev/null; then
	lines="$POLL_LINES_MAX"
	fi
	# 5+ digits necessarily exceeds POLL_LINES_MAX (2000) and would overflow
	# `test -gt`, whose failure would otherwise skip the clamp entirely.
	case "$lines" in
	[0-9][0-9][0-9][0-9][0-9]*) lines="$POLL_LINES_MAX" ;;
	0) lines=50 ;;
	esac
	if [ "$lines" -gt "$POLL_LINES_MAX" ] 2>/dev/null; then
	lines="$POLL_LINES_MAX"
	fi

---

Generated by Claude Code

[openwrt-ai]

json_escape is not defined in this file — it only exists in root/usr/libexec/rpcd/fwlive, which sources this one. Every other consumer sees an undefined command.

That is exactly what the package's own prerm does: Makefile:27-32 runs . /usr/libexec/fwlive-logging.sh standalone and calls restore_wan_log_baseline, which reaches json_null_or_string → json_escape. On uninstall that emits json_escape: not found on stderr and silently yields an empty esc. Same for logging_blockers_append on line 249.

The value is only used in JSON error strings here, so nothing is corrupted today — but the dependency is inverted and will bite the first time a status field is derived from it. Move json_escape into this file (or a third shared fwlive-json.sh sourced by both) so fwlive-logging.sh is self-contained.

---

Generated by Claude Code

[openwrt-ai]

This loop is per-entry, and the multiplier upstream is large. The view registers poll.add(this.pollFn, 1) and every tick asks for the full ring — [`callFwlivePoll({ addresses: [ String(constants.FETCH_LINES_MAX) ] })`](https://github.com/openwrt/luci/blob/91b462957c8dfc3cec197b22124d7c26e59bbb92/applications/luci-app-fwlive/htdocs/luci-static/resources/view/status/fwlive.js#L734)`` with FETCH_LINES_MAX: 2000, regardless of the user's row limit.

Per entry this spawns one jsonfilter (line 30) plus, inside is_firewall_event_msg, one sed with 15 expressions, one tr, and up to eight grep invocations (_detect_action, _has_kv ×N, _has_firewall_hint). That is roughly ten fork+exec per log line, i.e. on the order of 10–20k processes per second on a busy WAN-logging router, once per second, for every open browser tab. On the low-end targets LuCI status pages are expected to run on, that will dominate the CPU.

Two changes would fold it to a near-constant cost per poll:

• extract @.log[*].msg in the same jsonfilter pass (or emit entry+msg together) instead of re-invoking jsonfilter per entry;
• reimplement is_firewall_event_msg as a single awk program that reads the whole batch on stdin and prints the passing entries — the classification is all regex/substring work that awk does natively, and it removes the sed/tr/grep chain entirely.

Sending only rowLimit lines rather than always 2000, and a poll interval above 1s, would reduce the multiplier as well.

---

Generated by Claude Code

[openwrt-ai]

nit: this block is a no-op here. SOURCE_DATE_EPOCH is already exported by the buildroot for every package build, and no other package Makefile in this tree (applications/, modules/, protocols/, themes/) carries such a block. The comment also refers to docker-sdk.sh, which is tooling from the out-of-tree fwlive repo and does not exist in openwrt/luci.

Suggested change

	# Reproducible build: honor SOURCE_DATE_EPOCH from the build environment (set by docker-sdk.sh / CI).
	ifdef SOURCE_DATE_EPOCH
	export SOURCE_DATE_EPOCH
	endif

---

Generated by Claude Code

[openwrt-ai]

nit: a hand-maintained "keep in sync" constant will drift. luci.mk's SubstituteVersion only rewrites PKG_VERSION markers in *.htm and *.ut — luci.mk:288-298 — so nothing in the build will catch APP_VERSION falling behind PKG_VERSION:=0.1.36, and with the app also versioned in the out-of-tree repo that is three places to bump. If the value is only shown in an "about" line, consider reading it from the installed package metadata (or dropping it) instead of duplicating the literal.

---

Generated by Claude Code

[openwrt-ai]

nit: the PR description states this is "a copy into the luci feed, not a move", with the canonical sources (and a separate signed binary feed) staying at lucas-albers-lz4/fwlive. That leaves two copies of ~5.4k lines that will diverge — and the generated artifacts here (fwlive-is-firewall-event.sh is marked "Snapshot from the fwlive monorepo … Do not edit by hand. … regenerate upstream of this tree", and constants.js mirrors the upstream PKG_VERSION) mean a LuCI maintainer cannot fix a bug in-tree without it being overwritten by the next snapshot.

Worth stating explicitly for the maintainers: which tree wins when they conflict, and are you committing to keeping this copy current in openwrt/luci? luci-app-https-dns-proxy is the cautionary precedent this feed already has for an app maintained in two places. If the answer is that upstream wins, a PKG_SOURCE-based package pulling the release tarball would avoid the duplication entirely.

Also, the README's Dependencies section lists only luci-base and logd; getent (see the resolve comment) and the assumption that jsonfilter is present belong there too.

---

Generated by Claude Code

[lucas-albers-lz4]

Re-cut from fwlive with the post-review follow-ups (BusyBox-safe WAN lock dir check, jsonfilter stdin for large rings, poll error surfaced in the UI, !fw4: label precedence, iptables-save timeout + rules map bounds).

Fork tip: lucas-albers-lz4/luci luci-app-fwlive-add @ 2defca544d.

[openwrt-ai]

Reviewed 3 new commits since 91b4629.

The previous round's two functional findings are genuinely fixed: the rules map is now assembled in the current shell via <"$_rules_dump" redirects (and __rulesmap_iptables exercises the same two-pass path), and resolve uses BusyBox nslookup. poll_clamp_lines and the single-awk classifier both check out — I ran dash root/usr/libexec/rpcd/fwlive __selftest and _fwlive_filter_json_entries against a sample batch locally and they behave as documented. The stat -c → test -O + find -perm swap in #232 is correct for stock OpenWrt: BUSYBOX_DEFAULT_FEATURE_STAT_FORMAT is n while FEATURE_FIND_PERM, FEATURE_FIND_PAREN and FEATURE_FIND_PRUNE are all y in package/utils/busybox/Config-defaults.in.

One of the inline findings is a hard blocker for a feature the PR advertises: the nslookup resolver now works, but the client double-unwraps the reply (expect: { names: {} } and res.names), so hostnames are still never displayed. Worth confirming on a device before merge.

Commit checks

• 05a223d2 "luci-app-fwlive: sync #8992 with fwlive master" — the message does not match the diff. It claims "Refresh the .pot via i18n-scan.pl", but the commit touches no po/ file (only fwlive-is-firewall-event.sh, fwlive-logging.sh, rpcd/fwlive). It also credits itself with "rules map delivery, poll clamp, nslookup resolver, jsonfilter declare, classifier codegen, json_escape in logging.sh" — all of which landed in the preceding commit 79019f0; jsonfilter declare is a Makefile change this commit does not contain. What it actually does is add the _fwlive_tmp_dir_ok sticky-bit gate on /tmp, strip the trailing dot in the Address N: branch of parse_nslookup_name, add the __tmp_dir_ok CLI hook, and reorder the selftest so run_logging_selftest runs before the jshn-gated early return. Please rewrite the body to describe that.

---

Generated by Claude Code

[openwrt-ai]

The reply is unwrapped twice, so this is always {} and "Show hostnames" still cannot display a name.

callFwliveResolve declares expect: { names: {} },`` and rpc.js applies that before resolving the promise — ret = ret[key], then the type check falls back to the default. So `res` is the names map (`{"8.8.8.8":"dns.google"}`); `res.names` is `undefined`, and `names` is `{}` on every call.

Consequence: names[ip] is never truthy, every IP in need takes the else branch and gets hostname.failMarked, and updated stays false. The getent → BusyBox nslookup fix in 79019f0 makes the backend work, but the client discards the result, so the feature is still dead end-to-end.

Suggested change

	const names = (res && res.names) || {};
	const names = res || {};

The alternative is to drop expect from the declaration (like poll in this same commit) and keep res.names here — but then this path also has to handle the {"names":{},"error":"no_resolver"} reply that resolve_addresses returns, which the expect form currently collapses to {}.

---

Generated by Claude Code

[openwrt-ai]

This line does not do what the function's contract comment ("fails closed (return 1) only if the lock file cannot be opened") says, and it has a side effect on the success path.

Three things, all verified with dash:

$ dash -c 'acq(){ exec 9>"/nonexistent-dir/x.lock" 2>/dev/null || return 1; }; \
    if acq; then echo acquired; else echo "acq failed"; fi; echo "still alive"'
dash: 1: cannot create /nonexistent-dir/x.lock: Directory nonexistent
$ echo $?
2

1. || return 1 never runs. A redirection error on exec with no command aborts a POSIX non-interactive shell (dash/BusyBox ash). Under rpcd that kills the plugin mid-call, so enable_wan_logging / disable_wan_logging return no body at all instead of {"ok":false,...,"error":"lock_failed"}; in prerm it aborts before exit 0.
2. 2>/dev/null does not suppress that message — redirections are applied left to right, so 9> is attempted before 2 is reassigned (note the diagnostic above is still printed).
3. On the success path 2>/dev/null is permanent. exec with no command makes both redirections stick, so every later uci set / uci commit / flock diagnostic in this process is discarded and never reaches rpcd's stderr handler. release_wan_log_lock does not restore it.

Probing in a subshell keeps the guard working and confines the 2>/dev/null:

Suggested change

	exec 9>"$WAN_LOG_LOCK_FILE" 2>/dev/null || return 1
	# Probe in a subshell first: a failed `exec` redirection aborts a POSIX
	# non-interactive shell outright, so `|| return 1` on the real exec would
	# never run — and `2>/dev/null` on the same exec would permanently
	# silence this process's stderr on the success path.
	( exec 9>>"$WAN_LOG_LOCK_FILE" ) 2>/dev/null || return 1
	exec 9>>"$WAN_LOG_LOCK_FILE"

(>> rather than > also avoids truncating the lock file — pointless flash traffic for /etc/fwlive/logging.lock.)

---

Generated by Claude Code

[openwrt-ai]

nit: build_rules_map now emits an error field (mktemp_failed from _fwlive_mktemp, or rules_truncated once RULES_MAP_MAX_KEYS/RULES_MAP_MAX_BYTES trip — see rpcd/fwlive:324-330), but nothing here reads it: a truncated or empty map renders identically to a router with no labelled rules.

That is the inverse of what this same commit did for poll, where expect was dropped specifically so reply.error could reach the banner (#233). Truncation is reachable in practice — map_uci_rule_names adds up to two keys per UCI rule before any nft prefix is seen, so ~256 firewall rules exhaust the 512-key budget and every nft log prefix label is dropped silently. Worth surfacing the same way the poll error is, or at least logging it to the console.

---

Generated by Claude Code

[openwrt-ai]

nit: leftover double blank line from removing the SOURCE_DATE_EPOCH block. No other applications/*/Makefile in the tree has a blank-line gap here.

Suggested change

---

Generated by Claude Code

[lucas-albers-lz4]

Re-cut from fwlive master after #238 + round-2 fixes (#243–#246): resolve double-unwrap (hostnames), WAN lock probe (no POSIX abort / stderr silence), rules map error in the UI, cut Makefile blank squeeze. Refreshed .pot via i18n-scan.pl.

Fork tip: lucas-albers-lz4/luci luci-app-fwlive-add @ 593ce11d20.

[openwrt-ai]

Reviewed 1 new commit since 2defca54.

The three findings from the previous round are correctly fixed. resolve no longer double-unwraps (expect: { names: {} } means res is the map, so const names = res || {} is right), the WAN lock now probes in a subshell so a failed exec redirection can't abort the shell or permanently silence its stderr, and the .pot really was refreshed — the three new Rule labels … strings are the only msgid additions in the template diff, matching i18n-scan.pl output.

The new rules-error UI has a side effect worth a second look: because loadRulesMap() runs once and lastRulesError is never cleared, a rules_truncated map (reachable at ~256 UCI rules) permanently replaces the live row counter for the rest of the session, unlike the self-clearing poll error it is modelled on. Inline.

CI is green on 593ce11d (build x86_64, eslint, CodeQL, FormalityCheck all pass).

Commit checks

• 593ce11d "luci-app-fwlive: refresh snapshot for openwrt-ai round 2" — the body lists four changes plus the .pot refresh, and all four are present, but the diff also contains a fifth that the message does not mention: run_with_timeout in root/usr/libexec/rpcd/fwlive changes its no-timeout fallback from running the command unbounded to return 127. That is a behaviour change affecting backend detection, the rules map and hostname resolution — not a refactor — and it deserves a line in the body (the in-code comment cites #229, but the commit message does not).

---

Generated by Claude Code