[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] Fw: new file format
From:       Guy Harris <guy () alum ! mit ! edu>
Date:       2004-10-06 21:57:56
Message-ID: C7EF9CDA-17E2-11D9-9564-000A958097E4 () alum ! mit ! edu
[Download RAW message or body]


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.
[prev in list] [next in list] [prev in thread] [next in thread]