Debugging a sash64 Netboot on the Origin 200

To install and boot IRIX the way the hardware does, the emulated machine has to run the stock SGI firmware and let it pull its standalone shell, sash64, over the network. No disk, no filesystem, just the firmware asking a boot server for a file and running it. The machine already ran the firmware, and the firmware already talked to the network, but the netboot stalled. What surprised me was where. Not in the SGI machine model at all, but in the ordinary user-mode network stack the emulator uses to answer, which turned out to be stricter than the real servers the firmware was written against.

Two separate things were in the way, and both came down to the same awkward question: when the emulator’s network code and the vendor firmware disagree, which one is wrong? I couldn’t answer that from inside the emulator, because we wrote one side of the argument. It had to be settled against something neither side controlled.

The first was a padded read request. The firmware asks for its boot file with a standard TFTP read request, and ours arrived with a tail of uninitialised buffer bytes after the transfer mode. Junk, but harmless junk, the kind a real server skips over. Our network stack didn’t skip it. It expected the option region to be cleanly terminated and readable to the end of the packet, hit the padding, and rejected the whole request as malformed. The boot file was never sent.

My first fix just cut the request off at the transfer mode and ignored the rest. It worked, and it was within the letter of the protocol, but a review caught that it threw away the real, well-formed options sitting between the mode and the padding, quietly forcing an option-capable client down to the smallest, slowest transfer size for no reason. dnsmasq doesn’t do that. It walks the options field by field and stops at the first field with no value, keeping every complete option and dropping only the trailing rubbish. I redid the fix to walk the same way, so it now parses the firmware’s request field-for-field the way dnsmasq would. The test I wrote to pin it fails first: for each shape of padding I’d seen after a real option, the server still has to acknowledge that option, and the blunter first fix didn’t.

The second showed up later in the same netboot, when the firmware reloads sash64 through a second address-assignment round. On that round the firmware fills in its own address in the request. It already knows who it is, and it’s telling the server where to send the answer. Our stack ignored that and broadcast the reply to the whole network, the way it would for a first-time client with no address yet. A client that has announced its address and is waiting for a directed reply doesn’t necessarily see a broadcast, and this one didn’t. The fix is one condition: when the client has filled in its own address, send the reply there instead of broadcasting it, which is what RFC 1542 says and what dnsmasq does.

Either fix could have been tuned until this one emulated boot happened to work, and that would have proven nothing about the firmware. So I checked both against evidence from outside the project. I compared the firmware’s packets against a real Octane2’s, a different SGI machine running the same class of firmware, captured on a live network, which established that the padded request and the address-filled reload are what the hardware does and not artifacts of our machine. And I matched the server side against dnsmasq rather than inventing it, so the emulator now accepts what dnsmasq accepts and refuses what it refuses. The changes are small enough that a formatting-only diff against the pristine upstream source shows they add nothing beyond the two behaviours themselves, and they’re packaged as a short series aimed at the upstream library.