[bong-water-water-bong]

Board, c22 stick (rc-2026-11-04-c22), 4 Nov 12:5x AST — TOS3-C23-NOTES.md item 1: "mDNS is announced but
unreachable: avahi says '1bit-os.local is announced', yet a raw mDNS query from ryzen gets no answer."

Root cause

#952/#953 put the responder in the image and it runs — the c22 image logs 1bit-os.local is announced on this network. What was never opened is the path for a query, and the cause is the same rc.firewall that
zz-onboard-ports already works around for TCP. Read out of the packed c22 puppy SFS, etc/init.d/rc.firewall:

-P INPUT DROP
-A INPUT -p ALL -d 224.0.0.1 -j DROP                 # only .1; a query to 224.0.0.251 gets past this
-A INPUT -p UDP -j udp_inbound
     udp_inbound: -p UDP --dport 137/138 -j DROP
                  -p UDP --sport 67 --dport 68 -j ACCEPT
                  -p UDP -j RETURN                    # back to the DROP policy
-A INPUT -m pkttype --pkt-type broadcast -j DROP
-A OUTPUT -p ALL -j ACCEPT                           # why the announcements DID reach the wire

Every NEW inbound UDP packet falls through to DROP, and an mDNS query is exactly that packet. The appliance's own
announcements are outbound and always left, which is why avahi reported success while nothing answered.

Fix (one file, one function)

os/v3/puppy/embed/etc/init.d/zz-onboard-ports — an INPUT ACCEPT for udp/5353:

• LAN-only, the same four ranges the same file already adds to hosts.allow (10/8, 172.16/12, 192.168/16)
  plus 169.254/16 for avahi's no-lease fallback: announcing to a phone on the LAN is the point, being a public
  responder is not;
• inserted at position 1, i.e. ahead of udp_inbound and of the broadcast drop, which is the whole reason a port
  rule for UDP has to live in this file;
• -C first, so a re-run is a no-op, same shape as the two port rules already here;
• in zz-onboard-ports and not 18onboard-mdns: the name is the mechanism, rc.firewall sorts under "r" and
  would wipe a rule set by a 18- service.
• IPv6 is deliberately not opened (shortcut: comment in the file): this image's IPv6 is unconfigured and the board
  reaches it at 192.168.50.110, so a v6 rule would be untested code.

vm-check.sh gains U3 mdns rule, which fails an image without the rule (the same reasoning as the existing
U3 port rule row) and prints the responder's own last log line.

Measured (booted c22 image, ~/wt/os3i/c23-mdns-probe6.sh, one controlled announcement burst per arm)

The counters are the rules' own, so this is the packet path talking, not a grep:

arm	policy DROP	the fix's INPUT rule
shipped firewall	5 → 12 packets (+7 / 2095 B)	absent
+ one -I INPUT 1 -p udp --dport 5353 -s 10.0.0.0/8 -j ACCEPT	12 / 2868 B (unchanged)	0 → 7 packets / 2095 bytes
rule removed again	12 → 19 (+7 / 4963 B)	absent

The seven packets dropped in arm 1 are the seven the rule accepts in arm 2, byte for byte, and arm 3 puts them back
on the drop path. udp_inbound counted 16 packets in arm 1, so the burst really did traverse the chain.

Two limits, stated rather than implied:

1. Those packets are avahi's own multicast announcements looped back (IP_MULTICAST_LOOP), not a query from a
   peer. Same packet class (udp → dport 5353, inbound, real interface), same chain, and the rule is blind to who
   sent it — but "a peer on the LAN resolves 1bit-os.local and gets :13305 200" is the board row and stays
   SKIP U4 board in the harness.
2. QEMU user networking cannot carry inbound UDP at all: a hostfwd=udp:…-:5353 delivers nothing to a guest
   listener even with iptables -F; -P INPUT ACCEPT (policy counter 0 packets). A veth pair does not help either —
   both ends are one host's addresses, so the route is local via lo — and this image's ip is BusyBox, which has
   no netns subcommand. All three dead ends are recorded in the probe scripts so the next lane does not pay for
   them again.

Closes #1011.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit b27ba43)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 952 - Partially compliant Compliant requirements: The image now includes the mDNS responder and client name resolution components. The boot service 18onboard-mdns starts the D-Bus system bus and avahi-daemon. The nsswitch.conf is updated to include mdns4_minimal. The image refuses to be published without both components. The vm-check now asserts that the name resolves on the box. Non-compliant requirements: None Requires further human verification: End-to-end verification that a peer on the LAN resolves 1bit-os.local and gets :13305 200 (requires physical hardware). 953 - Partially compliant Compliant requirements: The appliance now announces 1bit-os.local. The blank-key check no longer asks for a key. The appliance correctly sends no header in blank mode. The appliance correctly sends the real key in keyed mode. The release-check.sh now correctly asserts that the check passes. Non-compliant requirements: None Requires further human verification: None 1011 - Partially compliant Compliant requirements: The firewall no longer drops mDNS queries. The appliance accepts mDNS queries on UDP port 5353. The fix is implemented in zz-onboard-ports to open UDP port 5353 for LAN ranges. The U3 mdns rule row is added to vm-check.sh to verify the rule exists. Non-compliant requirements: None Requires further human verification: End-to-end verification that a peer on the LAN resolves 1bit-os.local and gets :13305 200 (requires physical hardware).

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Firewall Rule Insertion The script adds iptables rules to allow mDNS queries on UDP port 5353 from specific LAN ranges. It uses -I INPUT 1 to insert the rules at the beginning of the INPUT chain, ensuring they are processed before other rules that might drop the packets. This is a correct approach to ensure that mDNS queries are not dropped by the firewall. open_mdns() { for src in 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16; do iptables -C INPUT -p udp --dport 5353 -s "$src" -j ACCEPT 2> /dev/null && continue iptables -I INPUT 1 -p udp --dport 5353 -s "$src" -j ACCEPT 2> /dev/null && continue echo "zz-onboard-ports: could not open udp/5353 for $src" >&2 return 1 done } # shortcut: IPv4 only. 18onboard-mdns's responder answers on both families, but this image's IPv6 is # unconfigured (no global address, and the board reaches it at 192.168.50.110), so a v6 rule would be untested # code; add fe80::/10 to this loop when the appliance gets an IPv6 address. open_mdns Self-test Script The self-test script mdns-ports-selftest.sh verifies that the zz-onboard-ports script correctly inserts the necessary iptables rules for mDNS. It uses a stub iptables command to simulate rule insertion and checks that the rules are inserted correctly and idempotently. This ensures that the script behaves as expected. cat > "$work/bin/iptables" <<'STUB' #!/bin/sh # the rule's identity is "<chain> <spec...>", so `-I INPUT 1 <spec>` and `-C INPUT <spec>` compare directly echo "$*" >> "$CALLS" cmd=$1; shift chain=$1; shift case $cmd in -C) grep -qxF "$chain $*" "$STATE" 2>/dev/null && exit 0; exit 1 ;; -I) shift; echo "$chain $*" >> "$STATE"; exit 0 ;; -S) printf '%s\n' '-A INPUT -p tcp -m tcp --dport 13305 -j ACCEPT' '-A INPUT -p udp -m udp --dport 5353 -j ACCEPT'; exit 0 ;; *) exit 0 ;; esac STUB chmod +x "$work/bin/iptables" PATH="$work/bin:$PATH" sh "$script" > "$work/run1.log" 2>&1 i1=$(grep -c -- '^-I ' "$CALLS") c1=$(grep -c -- '-dport 5353' "$CALLS") u1=$(grep -c -- '^-I .* -p udp --dport 5353 ' "$CALLS") PATH="$work/bin:$PATH" sh "$script" > "$work/run2.log" 2>&1 i2=$(grep -c -- '^-I ' "$CALLS") u2=$(grep -c -- '^-I .* -p udp --dport 5353 ' "$CALLS") c2=$(grep -c -- '-dport 5353' "$CALLS") echo "run 1: $i1 insert(s), $u1 of them udp/5353, $c1 udp/5353 command(s)" echo "run 2 (same ruleset): $((i2 - i1)) insert(s), $((c2 - c1)) udp/5353 command(s) - all -C, none -I" fail= [ "$i1" -ge 6 ] || fail="$fail first-run-inserts=$i1(expected 6: two TCP ports, four udp/5353)" [ "$u1" -eq 4 ] || fail="$fail udp5353-inserts=$u1(expected 4)" [ "$u2" -eq 4 ] || fail="$fail re-run-inserted-udp5353=$u2(not idempotent)" [ "$((c2 - c1))" -eq 4 ] || fail="$fail re-run-udp5353-commands=$((c2 - c1))(expected 4 -C and no -I)" for src in 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16; do grep -qxF "INPUT -p udp --dport 5353 -s $src -j ACCEPT" "$STATE" || fail="$fail missing-rule-$src" done if [ -n "$fail" ]; then echo "RESULT: FAIL -$fail" exit 1 fi echo "RESULT: PASS (four udp/5353 rules inserted once, the re-run inserts nothing, sources as intended)"

[bong-water-water-bong]

VERDICT: READY

The diagnosis is right and I reproduced both halves of it in a private network namespace — no box firewall touched,
unshare -rn with lo up, rc.firewall's UDP shape rebuilt from the diff's own listing:

  before the rule:   listener TIMED OUT (no query arrived)      <- the c22 board symptom, reproduced
  after  iptables -I INPUT 1 -p udp --dport 5353 -s <src> -j ACCEPT:
                     listener RECEIVED 10 bytes from 127.0.0.1
  chain afterwards:  -P INPUT DROP
                     -A INPUT -s <src>/… -p udp -m udp --dport 5353 -j ACCEPT
                     -A INPUT -d 224.0.0.1/32 -j DROP
                     -A INPUT -p udp -j udp_inbound

So "announced but never answers" is exactly what -P INPUT DROP + udp_inbound's -j RETURN does to a query, and
-I INPUT 1 is the position that fixes it (ahead of the 224.0.0.1 drop and of udp_inbound). The substitute I made
is the source: 127.0.0.1/32 for one of the four LAN ranges, since a loopback source is what a single netns can produce;
the match semantics are the same and the ranges themselves are declared and -C-tested by the new row.

Idempotency, which is the other thing a rule-inserting init script can get wrong — ran the function three times in
the same namespace:

run1 rc=0 rules=4   run2 rc=0 rules=4   run3 rc=0 rules=4

one rule per range, stable, because -C short-circuits before -I.

bash -n clean on both files and shellcheck reports 0 findings on zz-onboard-ports (8 lines of open_mdns included).

Three notes, none a gate:

1. The broadcast drop is not what was biting, and the test says so. My query was unicast, so the path proven is
   udp_inbound -> DROP policy; -m pkttype --pkt-type broadcast -j DROP never matched (mDNS is multicast, not
   broadcast). Worth knowing if someone later "simplifies" the ordering — the -I INPUT 1 is doing the work for the
   common case, and the 224.0.0.1 DROP would only matter for a query sent to the all-hosts address, which mDNS does not.
2. open_mdns's return value is ignored at the call site, exactly like the two open_port calls above it — so a failed
   insert prints to stderr and the script still finishes 0. Consistent with the file, but it means a boot with no
   iptables would be quiet in the exit status. The new U3 mdns rule row (asserting udp-5353-open) is what actually
   catches it, which is the right place for it.
3. IPv4-only is declared as a shortcut: with the condition for upgrading (a global v6 address), which is the form I
   want to see. No mDNS over v6 on this image today, so nothing is lost.

Not run by me: the guest rows themselves (U3 mdns rule, and the responder's own log line) — they need the VM or the
c22 stick, and I mount nothing on this box.

[github-actions]

Persistent review updated to latest commit 9c0b734

[bong-water-water-bong]

VERDICT: READY (re-verdicted at 9c0b73487)

The push adds os/v3/puppy/mdns-ports-selftest.sh (+78), which is the right answer to "this is the kind of code that
fails silently". I ran it, and then ran it against the pre-fix script as a control:

$ sh os/v3/puppy/mdns-ports-selftest.sh  os/v3/puppy/embed/etc/init.d/zz-onboard-ports
run 1: 6 insert(s), 4 of them udp/5353, 8 udp/5353 command(s)
run 2 (same ruleset): 0 insert(s), 4 udp/5353 command(s) - all -C, none -I
RESULT: PASS (four udp/5353 rules inserted once, the re-run inserts nothing, sources as intended)

$ sh os/v3/puppy/mdns-ports-selftest.sh  <the same file at origin/main>
RESULT: FAIL - first-run-inserts=2(expected 6: two TCP ports, four udp/5353) udp5353-inserts=0(expected 4)
        re-run-inserted-udp5353=0(not idempotent) … missing-rule-10.0.0.0/8 missing-rule-172.16.0.0/12
        missing-rule-192.168.0.0/16 missing-rule-169.254.0.0/16

So the check discriminates in both directions and it also pins that the two pre-existing TCP ports are still opened —
which is the regression a wrapper like this most plausibly causes. sh -n clean on both files.

This stands alongside the netns result from my earlier review (query dropped before the rule, delivered after it, rule at
the top of INPUT), and it does not need root, a device or a real ruleset.

[bong-water-water-bong]

#1016 ready for review at 9c0b734

[bong-water-water-bong]

VERDICT: READY at d0b5f7194 — merge-only update; the delta is #1007 arriving from main.

git diff 9c0b7348 d0b5f7194 -- os/ is os/v3/puppy/g3-probe.sh | 5 +++++-, i.e. main's -1bit release-spelling fix
and nothing of this PR's own three files. So the evidence carries: the netns result (query dropped before the rule,
delivered after, rule at the top of INPUT), the rule's idempotency (4 rules after three runs), and the new
mdns-ports-selftest.sh (PASS at the head, RESULT: FAIL against the pre-fix script).

Note for the merge sweep: #1020 is stacked on this PR (merge-base --is-ancestor on this head -> yes), so #1016 goes
first and #1020 second, or #1020 needs a rebase.

[github-actions]

Persistent review updated to latest commit b9991d8

[github-actions]

Persistent review updated to latest commit b27ba43