Sorry I didn't get around to this until now, but....
On Jul 30, 2004, at 1:09 PM, Gianluca Varenni wrote:
There is another issue related to these block types.
Fulvio's proposal:
a shb (even corrupted by the ftp transfer) can begin with the following
strings:
\r\n\r\x1A -> 1 reserved block type
\r\n\n\r -> 1 reserved block type
\n\r\x1a\?? -> 256 reserved block types
\x1a\r\n\r -> 1 reserver block type
\x1a\r\r\n -> 1 reserved block type
\x1a\n\r\?? -> 256 reserved block types
As a consequence we have 516 reserved block types (and we need at least 6
checks to test if a block has one of these 516 special types). With 6 check
we are able to see if the block is a proper section (and its byte order), a
ftp transfer error, or a normal block.
Gianluca's proposal: a shb (even corrupted by the ftp transfer) can begin with the following strings: \r\n\n\r -> 1 reserved block type \n\n\r\?? -> 256 reserved block types \r\r\n\r(\n\r) -> 1 reserved block type
I'm not sure what all the possible forms of damage can be; the most common forms would be Un*x <-> Windows, which would *probably* turn \r\n\n\r into \n\n\r?? for W->U and into \r\r\n\r for U->W, although weirdness might happen if the last \r happened to be followed by \n, and I don't know what particular Un*x FTP clients would do if they saw \r\n or what particular Windows clients would do if they saw \n not preceded by \r.
Other less-likely damage would be those with pre-OS X Mac OS clients (which would think \r is the line ending) or other OSes, but those don't support libpcap/WinPcap or tcpdump/WinDump or Ethereal or... as far as I know, so I'm not sure they're worth worrying about.
As an SHB has to have a byte-order magic number in it, it's probably likely that some other block type would not be mistaken for an SHB. If non-private-use block types other than the SHB block type are assigned starting at 0, they'll probably be small integers for a long time, so none of the mangled SHB block types are, I suspect, likely to match them; private-use block types have the high-order bit set, and if they're also made 0x80000000|{small integer}, that'll probably be safe as well.
It might be interesting to try the most popular Windows, Un*x, and "written for OS X" (as opposed to "written for Un*x so they happen to work on OS X") FTP clients - or, at least, the ones we have access to - to see how they mangle things; trying HTTP clients might be interesting as well. I'm not sure it's worth the effort, though.
As a consequence we have 258 reserved block types (and we need at least 3
checks to test if a block has one of these 258 special types).
If the block type is "\r\n\n\r" we need at most two other tests to look for
the byte order.
Two? I.e., checking for 0x1A2B3C4D and 0x4D3c2B1A at an offset of 8 from the block type?
If the block type is "\n\n\r\??" or "\r\r\n\r" we need some tests (I do not
know how many of them) to look for the byte order in the file and find if
it's an invalid block or a ftp tranfer error.
In
http://www.tcpdump.org/lists/workers/2004/07/msg00128.html
I calculated that the byte offset of the byte-order magic would probably be between 2 and 14 bytes from the beginning of the block (i.e., from the start of the block type), so that'd be 13*2 or 26 tests.
Any final decision for this issue??
I'd vote for Gianluca's proposal. Anybody else?
Are there any other outstanding issues in the file format?
- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
