9line.git/fw/test, branch master

svc: /mnt/fw/ether0 needs an mntgen of its own

2026-08-19T17:00:26+00:00

The service file said -m /mnt/fw/ether0 and nothing made that name. mntgen invents names one level deep, so the one over /mnt gives /mnt/fw and stops there: one mntgen over /mnt makes /mnt/fw yes but not /mnt/fw/ether0, which is where fw is told to mount no a second one over /mnt/fw does yes So a second mntgen over /mnt/fw, as its own service, and every fw needs it. It is a file server like the rest -- posts its name, lets the process that started it exit -- so ready=srv:mntfw, the same shape fw uses. fwstart already does this imperatively, which is why the boot path worked and the supervised path would not have. Four checks now pin the premise both rest on, ending with fw actually mounting its control files under the second mntgen. The finding and the service file are Calvin's; the checks are mine. Co-Authored-By: Claude Opus 5

test: put fw on a wire, with another machine on the other end

2026-08-19T16:54:29+00:00

Everything in fwtest.rc happens on one machine, which is as far as it goes: it can take a spare card and watch what fw does to the interfaces, but it cannot make a neighbour send anything. Four things were listed as never tested for that reason. Three of them now are. run.sh -gw and -lan join two VMs into a point-to-point segment, so the peer is a plain overlay of the base with an address and nothing else. ARP first, since it is the part with no other explanation: the stack that owns 10.9.9.1 has a pkt interface and no ethernet, so nothing else on that segment can answer for it. The peer's arp table: ether OK 10.9.9.1 52540087c8c1 10.9.9.2 which is the firewall's card. The first ping takes about a second and the rest are sub-millisecond -- fw ARPing for the peer before it can reply, and dropping the first one while it asks, which is the drop no rule caused in fw(8) BUGS, until now only reasoned about. Then filtering as against forwarding, which cannot be seen from inside at all. With allow=in proto=icmp alone, a TCP connect from the peer sits for 290 seconds and times out; prepend a rule through ctl and the same connect is refused in 2. Refused is the far stack's RST, so the packet arrived; timed out is fw dropping it in silence. And frames addressed to somebody else, which is the commit that shipped saying it could not be tested without a second machine. A stack only addresses frames to the mac it resolved, so rawether.c forges one. A promiscuous reader on the firewall machine sees both frames, which had to be confirmed first -- a frame that never arrived looks exactly like one that was filtered, and my first attempt at this drew the wrong conclusion from precisely that. Same rig, same frames, same rules: to fw's card to nobody's no check +3 +3 with the check +2 0 test/wire.md is the procedure, including the two ways I wasted time: fw's control files need -s to be reachable from another shell, and anything that leaves fw holding a pipe waits forever for a program that has already detached. Co-Authored-By: Claude Opus 5

test: count what was skipped, and say how to stop skipping it

2026-08-19T16:31:10+00:00

The suite reported 73 passed, 0 failed on a machine where it had been reporting 87. Nothing had regressed: the VM had been booted without a second card, so the fourteen card-mode checks skipped. A skip printed one line among ninety and the total moved, and a total that moves is not a signal anybody reads -- 73 passed looks exactly as good as 87 unless you happen to know which to expect. So skips are counted with the rest: 87 passed, 0 failed, 0 skipped and the one that matters says what to do about it rather than only what is missing: boot with run.sh -gw and the spare card is there. The header says the same, since that is where someone looks first. Also finishes the proof the last commit could not. /sys/log/fw now has a line for every port the suite can pick, so the collision that made the old check fail by chance is certain: 3600 poison lines, and the delta version passes 87 while the total version fails both logging checks with 4 and 3 where 1 is right. Co-Authored-By: Claude Opus 5

test: the log is not this run's, so do not ask it for a total

2026-08-19T14:57:54+00:00

The suite failed on the second run of a pair, on the two checks that read /sys/log/fw: FAIL a denied connection is logged, with the rule that said so want: 1 got: 2 Not a firewall bug. The checks counted matching lines in the whole log, on the stated grounds that "the port is this run's, so the whole file can be searched". The port is 17000 + pid%900 and /sys/log/fw keeps every run there has ever been, so the port is this run's only until two runs pick the same one. Thirty entries over nine hundred ports is a two-in-five chance of a collision, and there it was: ports that appear more than once: 2 17538 So they are differences now, like the fragment count and the listen log before them. That is three checks in this suite that have had to learn the same thing: a check that reads a file which outlives the run must read it twice and subtract, because every other reading is a measurement of the machine's history. Verified passing; the stronger proof -- poisoning the log with a line for every port the suite can pick, so the collision is certain rather than likely -- did not finish, because the VM it was running on was shut down partway through. Co-Authored-By: Claude Opus 5

fw: a dead firewall leaves the network down, and can be restarted into it

2026-08-19T14:41:03+00:00

Two things can happen when a firewall dies: the traffic it was filtering carries on unfiltered, or it stops. Only the second is defensible. A machine briefly off the network is a machine somebody notices and fixes; a machine briefly on the network with no rules is the thing the firewall was installed to prevent, and nobody notices it at all. fw already does the second, in all three modes, and by mechanism rather than by care. Measured rather than assumed: before fw device: /net/ether1 addr: 10.9.9.1 route: 10.9.9.254 fw running device: pkt0 addr: 10.9.9.1 route: 10.9.9.254 fw killed device: addr: route: pktmedium is unbindonclose, so the interface and the address go when fw's fds close, and the card is left bound to nothing with nothing reading it. In a namespace it is harder still: /net answers "i/o on hungup channel" and bind -a '#I' /net answers "mount/attach disallowed", because the device mask was dropped before the program started. So todo item 1 -- "a dead fw takes the network with it", open since the first commit -- was the requirement written down as a defect. It is now design.md and a FAILURE section in fw(8), and the tests assert it, which is the point: this is exactly the property a later helpful change reverses without meaning to. putback() was that change, written and never run; deleting it removed a fail-open path, not just dead code. What was actually broken is recovery, and in a way nobody had reached: a fw that dies leaves its control filesystem mounted, and a corpse of a mount fails everything asked of it -- including the access() check fw makes before touching a card, which then refuses the restart: fw: /tmp/rdbg/ctl: clone failed; not touching /net/ether1 until it exists That check exists so fw does not take a card it cannot then serve, and it was keeping fw from ever coming back. Now the dead mount is cleared first, the same way reclaim() clears the pkt interface the same dead fw left behind: both are its own wreckage. With that and -a/-g in the service file -- so a restart does not need the address it just lost -- the whole cycle works and never passes through open: crash, network down, restart, network up and filtered. Ten checks, three of which fail against the previous fw.c. 87 pass. Co-Authored-By: Claude Opus 5

fw: make the /srv name worth watching, and say how to supervise it

2026-08-19T14:00:34+00:00

todo.md said fw daemonizing meant svc could not supervise it, and that it needed a foreground mode. Both wrong. svc has had the shape from the start. ready=srv: watches the /srv name rather than the pid, and its own manual says why: "Use this for a service that posts to /srv and lets the process you started exit, which many Plan 9 file servers do on purpose. For these the /srv file is watched and the process is not, so the process exiting is normal and never causes a restart." init.c agrees -- reap() returns early for Ksrv with that comment on it. Nor is detaching unusual. 42 commands under /sys/src/cmd use postmountsrv or threadpostmountsrv; five call srv() directly, and every one of those is a stdio server (ramfs -i, ext4srv -s, skelfs, hjfs, wacom) speaking 9P on file descriptors it was handed. That is not a foreground service, it is a pipe server: no /srv, no mount, nothing to supervise. A foreground mode for fw would buy a pid to watch, and the /srv name is the better signal -- it survives the process that made it. What was true underneath the wrong diagnosis: the name was not honest. Taking the control filesystem away ends the server proc, and the relays carried on filtering: procs: 3 ... take the ctl filesystem away ... procs after: 2 still filtering? pkt interface: pkt0 A firewall nobody can reach, stop, or notice, and the /srv name gone while it runs. Srv.end now takes the whole thing down, which is the answer the relays already gave when their wire failed. Same test after: three procs become none and the interface goes with them. So: no flag, an example service file in lib/svc, and a SUPERVISION section in fw(8) that says what init should watch and what restarting will and will not fix. Restart=always brings fw back; it does not undo taking the card, so the new fw has no address to read. Supervision works, recovery does not, and that stays open as item 1. Two checks. Against the previous fw.c they fail with two orphaned procs and a pkt interface still bound -- and so do the leak checks at the end of the run, which is what they were built for. 77 pass. Co-Authored-By: Claude Opus 5

fw: read the interface tables a line at a time, and test card mode at all

2026-08-19T03:20:19+00:00

learnaddr, reclaim and takecard each read a status or route file into a fixed 1024-byte buffer and split it into at most eight lines. I called this a defect that could lose the default route. It could not: routes come out sorted, and 0.0.0.0 sorts first, so the default route is on the first line of the table and both limits are reached long after it has been found. The report was wrong about the consequence. The limits are still worth removing, and one thing in there was a real mistake: learnaddr and takecard looked for the device name anywhere in the status text, addresses included, rather than in the field that holds it. An interface whose address contained the name of the device being looked for would have matched. Contrived, but there is no reason to be searching a blob for something that has a place of its own. Bio reads line by line, the device is matched against the device field, and nothing has a length limit any more. More to the point, none of this had ever been run. Card mode is outside the suite because taking the machine's card away is how you end up with no network -- but a second card that nothing is using can be taken safely. The suite now binds #l1 into /net, puts it in an IP stack of its own with an address and a default route, and hands it to fw with no -a and no -g: fw: /net/ether1 has 10.9.9.1/120, gateway 10.9.9.254 fw: took /net/ether1 away from .../ipifc/0 fw: protected .../ipifc/0 addr 10.9.9.1 /120 fw: default route via 10.9.9.254 Six checks on that: the address and gateway are read off the interface rather than repeated on the command line, the card is taken, what replaces it is a pkt interface at the card's mtu holding the same address, and the route the card carried is put back. Skipped when there is no spare card, which is why it says so rather than passing quietly. 72 pass. Co-Authored-By: Claude Opus 5

netfs: check the caller when there is one to check

2026-08-19T03:14:48+00:00

An announce names no peer -- at that moment nobody has called -- so matchrule skipped every rule naming an address, and "deny=in ip=1.2.3.4" did nothing at all in namespace mode while doing something real at the packet layer. The code said so and called it right: A rule naming a peer therefore cannot apply to an announce, which is right: at this point there is no peer to name. Right about the announce, wrong about the connection. A rule that silently does nothing is the failure this program refuses to accept from a mistyped attribute -- fw will not start rather than run with "prot=tcp" ignored -- and it should not accept it from itself. So the peer is asked about at listen time, when there is one. The fd that listen yields is the new conversation's ctl file; its number reads out of it at offset 0, so the program's own read, the one listen(2) makes to learn the same number, still sees it. remote and local give the peer and the port announced. If the rules refuse, the connection is hung up and the open fails, and the program never has it. The handshake has already happened by then: the kernel answered before listen returned, and no filter at this altitude can prevent that. That is the difference between a rule that is late and a rule that is decorative, and it is worth the distinction. Two checks, on the same pair of rule sets, differing only in whether the caller is refused; both fail against the previous netfs.c. They read /sys/log/fw as a difference rather than a total: the caller's port is ephemeral, so nothing in the line belongs to this run, and the log keeps what earlier runs put there. The machine's own address stands in for a peer, since this one has no loopback configured -- announcing 127.0.0.1 gets "not a local IP address", and announcing a bare port binds to :: and never sees a v4 call at all. 66 pass. Co-Authored-By: Claude Opus 5

fw: a fragmented datagram crosses

2026-08-19T02:23:00+00:00

Only the first fragment of a datagram carries the transport header, so every later one matched no port, and a rule set written in ports -- which is every rule set in fwrules(6) -- denied it. Measured, 3000 bytes of UDP over a 1500 mtu, against a rule permitting the port: passed 1 dropped 2 The first fragment crossed and the receiver waited for the rest until it gave up. The alternative this replaced was worse: reading ports out of a later fragment lets one whose payload bytes happen to look like an open connection through, which is a firewall evasion older than most firewalls. So the first fragment decides and the rest of the train inherits. The train is what the receiving stack reassembles on -- protocol, addresses, identification -- and lasts about as long as that stack will hold the pieces. A train whose head we never saw is judged on its addresses alone, and so is normally denied: it is either an attack or the tail of a datagram we already refused. Same measurement after: passed 3 dropped 0 and one rule decision for the datagram rather than one per fragment. IPv6 fragments live in an extension header, which fw does not walk, so none of this reaches them; that stays in BUGS. Four checks, three of which fail against the previous fw.c. The fourth -- the far stack's own InDatagrams -- is read as a difference across the exchange, not a total: an IP stack outlives the run that made it, and reading the total made the check pass on a build that had dropped two thirds of the datagram. Co-Authored-By: Claude Opus 5

fwstart: make the directory before mounting on it, and let go of the console

2026-08-19T02:10:28+00:00

if(! test -d /mnt/fw) mntgen /mnt/fw mount(2) needs its mount point to exist, so mntgen cannot create /mnt/fw -- and this ran it only when /mnt/fw was missing, which is exactly the case where it fails: mntgen: mount /tmp/mg/fw: file does not exist: '/tmp/mg' So on a machine that had never had a /mnt/fw, the control directories never appeared, and fw's own "not touching the card until the mountpoint exists" check then refused every card in the file. The script has never worked on a fresh machine. It has also never been run by the suite, which is the other half of why nobody noticed. Now the directory first, then mntgen only if it is not already there -- under mntgen every name exists, which is the test. Both mntgen and fw leave a server behind, and a server started from a shell keeps that shell's descriptors, so at boot they sit on the console's input and it reads as a wedged terminal. This is the trap CLAUDE.md documents; the script was walking into it. They get /dev/null. Three checks, and fwstart now gets run at all: a control directory appears, a card that is not there is reported and skipped, and nothing left running holds the descriptors we started it with. The first fails against the old script. The third does not, because the old script never started anything for want of the directory -- it guards the fix from here, not the bug that was there. Co-Authored-By: Claude Opus 5