I still have yet to get my 8227 to boot using all attempted concoctions of LANtastic. So, I'm starting to work with the protocol a bit and hopefully I'll end up with a usable bit of code that I can use to boot these things. I'm currently using a tcpdump of the boot process kindly donated by a fellow 8227 user. Also, much thanks to Dirk-Willem van Gulik for digging up a copy of the Novell Boot ROM Developer's Guide (PDF).
RPL frames are made up of what Novell calls Vectors (what I formerly called LTDs). Vectors are the triplet formed by two bytes of a Length field, two bytes of a Type field, and a (L-4) length Data field. The protocol is based on the nesting of this basic structure. The needed Vector types are listed in the table below. (Note that the Novell book does not abstract it this far. I like my way better, so that is whats diagrammed here.)
Container Vectors hold no data directly, but hold one or more further Vectors instead. Data Vectors (aka SubVectors) directly contain data of some sort (specific to type). Container Vectors always have the upper byte of their Type field set all low. You'll also notice that Container Types are evenly spaced at bit-angles. I suppose they could be combined, however RPL does not appear to do this.
| Type | Class | Description | Comments |
| 0001 | Container | FIND command | |
| 0002 | Container | FOUND command | |
| 0004 | Container | Search | Always contains a single Loader Information SubVector |
| 0008 | Container | Connect Info | Usually contains Frame Size SubVector and Connect Class SubVector |
| 0010 | Container | Send File Request Command | |
| 0020 | Container | File Data Response | |
| 4003 | Data | Correlator Vector (Dummy Sequence Number) | |
| 4006 | Data | Address Vector (Source MAC address) ["Ring address of this Adapter in Media Format"] | |
| 4007 | Data | Logical SAP Vector | Always 0xfc ("Remote SAP Value") |
| 4009 | Data | Frame Size SubVector (Maximum frame size) | |
| 400a | Data | Connect Class SubVector | Usually 0x0001 ["Class I ONLY"] |
| 400b | Data | Response Correlator | Always 0x00 ["Response Code"] |
| 400c | Data | Set Address Vector | Should always be 0x000000000000 ["Group Address NOT Supported"] |
| 4011 | Data | Sequence Number | |
| 4018 | Data | File Data Vector | Loads the included data at the address specified by the Loader Address Vector |
| c005 | Data | Loader Info SubVector | Usually L=0x24 and D is filled with mostly zeros also containing the phrase "SBNE2" |
| c014 | Data | First four bytes: Address of Data | Starts at Base Address and increments by (Vector.size-4) for each successive load |
| Second four bytes: Transfer Control Address | Ususually 00007c00 | ||
| Final byte: Flags ["Bit Significant Option Flag"] | Usually 0x20 | ||
Besides the Vectors, there are the parts of the ethernet header to work with. The Protocol Type field of the ether header should be set to 0x0056 for frames from the client, 0x003d for FOUND frames, and 0x05dc for File Data frames. There should then be three bytes immediatly following the ethernet header but prior to the top-level LTD container, of the values {0xfc, 0xfc, 0x03} (this is aparently some SAP wackiness).
Because of the above oddities, you CANNOT use tcpdump to debug this protocol. It does not give enough information in its header (namely, the ethernet type ID, which changes during protocol negotiation). I may throw together a patch for tcpdump if I get a chance. Otherwise, its "trivial" to throw together a basic non-parsing tcpdump equivelent using libpcap.
Oh, and all values are given in big-endian (network) byte order...