>From [EMAIL PROTECTED] Fri Jul 23 15: 06:15 2004
Return-Path: <[EMAIL PROTECTED]>
Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca
[205.150.200.181])
by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i6NJ4Jp01025
(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL)
for <[EMAIL PROTECTED]>; Fri, 23 Jul 2004 15:04:20 -0400 (EDT)
Received: from polito.it (terra.polito.it [130.192.3.81])
by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i6NIvMX19798
for <[EMAIL PROTECTED]>; Fri, 23 Jul 2004 14:57:22 -0400 (EDT)
Received: from [207.71.241.1] (HELO nelson)
by polito.it (CommuniGate Pro SMTP 4.1.8)
with SMTP id 6201350; Fri, 23 Jul 2004 20:57:13 +0200
Message-ID: <[EMAIL PROTECTED]>
From: "Gianluca Varenni" <[EMAIL PROTECTED]>
To: "Guy Harris" <[EMAIL PROTECTED]>,
"Loris Degioanni" <[EMAIL PROTECTED]>
Cc: "Fulvio Risso" <[EMAIL PROTECTED]>,
"Michael Richardson" <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Subject: Re: new file format
Date: Fri, 23 Jul 2004 11:57:07 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Status: No, hits=-16.8 required=4.0
tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS,
REFERENCES
autolearn=ham version=2.52
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)
Resent-To: [EMAIL PROTECTED]
Resent-Date: Sun, 25 Jul 2004 02:46:51 +0300
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-From: Michael Richardson <[EMAIL PROTECTED]>
Hi.
This morning I tried both the sequences "0x1a2b0d0a" and the reversed one
"ox0a0d2b1a" into a test file. Unfortunately, the second sequence is not
changed when the file is transfered from windows to unix, but the file DOES
change. The problem is that while transferring from windows to unix, "\r\n"
becomes "\n", but the sequence "\n\r" does NOT get changed into "\n".
The best solution that comes up into my mind is to leave the original
solution of using \r\n\n\r as the block type, and 0x1a2b3c4d as byte order
magic.
If the file is transfered from win to unix in ASCII mode, the file should
become
\n\n\r .......... In this case we recognize the first three characters
"\n\n\r", try to convert the first 12 bytes from unix-ascii to win-ascii,
and check the byte order magic at bytes 8-11.
If the file is transfered from unix to win in ascii mode, the file should
become
\r\r\n\r\n\r ....... In this case we recognize (for example) the first three
chars "\r\r\n" and try to convert the first n characters (24 chars??) from
win-ascii to unix-ascii, and check the byte order magic at bytes 8-11.
I think this will both recognize a correct dump file downloaded in ASCII
mode, a wrong file, and the byte order.
Have a nice day
GV
----- Original Message -----
From: "Guy Harris" <[EMAIL PROTECTED]>
To: "Loris Degioanni" <[EMAIL PROTECTED]>
Cc: "Fulvio Risso" <[EMAIL PROTECTED]>; "Gianluca Varenni"
<[EMAIL PROTECTED]>; "Michael Richardson"
<[EMAIL PROTECTED]>
Sent: Thursday, July 22, 2004 3:54 PM
Subject: Re: new file format
>
> On Jul 16, 2004, at 4:17 PM, Loris Degioanni wrote:
>
> > The solution that we propose is to use the proper value as the block
> > type of
> > the Section Header Block. For example, \r\n\n\r should solve the byte
> > order
> > problem (it's palindromic and so it allows to detect the block both on
> > a
> > big-endian and on a little-endian machine) and *sould* allow to detect
> > end-of-line problems.
>
> Well, it'd let us detect them, in the sense that code would refuse to
> read a file that got corrupted by being transferred in ASCII mode.
>
> However, we can't distinguish, for example, between a capture file
> FTP'ed from a Windows system to a UN*X system and a random file that
> happens to begin with "\n\n\r{random byte that happened to be the first
> byte of the section header block's total length}", so we won't be able
> to tell the user "this looks as if it started out as a valid file, but
> it was probably transferred in ASCII mode" rather than "this is not a
> valid file" - and, given that the reason I wanted that string in there
> was because people were reporting corrupted files on the Ethereal lists
> and, in at least some of those cases, that was the result of an
> ASCII-mode transfer (and I suspect most if not all of them were), I
> want programs to be able to say, with a high degree of confidence, "you
> trashed this file by transferring it in ASCII mode".
>
> Now, the byte-order magic should survive an ASCII-mode transfer (it
> survived the ASCII-mode transfer that produced the corrupted files
> mentioned in the previous paragraph); unfortunately, its offset in the
> file won't necessarily survive that.
>
> A magic of 0x1a 0x2b \r \n:
>
> 1) would be 0x1a2b0d0a in one byte order and 0x0a0d2b1a in the
> opposite byte order, so it'd serve as a byte-order magic;
>
> 2) would probably be turned into 0x1a 0x2b \n ? by an ASCII transfer
> from Windows to UN*X;
>
> 3) would probably be turned into 0x1a 0x2b \r \r \n by an ASCII
> transfer from UN*X to Windows;
>
> so supporting both 0x1a0x2b0d0a and 0x0a0d0x2b1a as block types for the
> Section Header Block, and eliminating the byte-order magic, should, I
> think, fix both problems - if the file begins with 0x1a 0x2b \n, or
> begins with 0x1a 0x2b \r \r, it's probably a capture file that was
> transferred in ASCII mode between UN*X and Windows.
>
> (I'll see if I can test both transfers, at least with the BSD FTP
> client - that being the one in most UN*Xes and in Windows - and
> whatever servers happen to be on the systems I try them on.)
>
>
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
