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

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 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions