tcpdump mailing list archives

[tcpdump-workers]

From: Michael Richardson <mcr () sandelman ottawa on ca>
Date: Sun, 25 Jul 2004 02:46:51 +0300

From gianluca.varenni () polito it  Fri Jul 23 15: 06:15 2004

Message-ID: <07f701c470e6$dac77430$5801a8c0@nelson>
From: "Gianluca Varenni" <gianluca.varenni () polito it>
To: "Guy Harris" <guy () alum mit edu>,
    "Loris Degioanni" <ldegioanni () ucdavis edu>
Cc: "Fulvio Risso" <fulvio.risso () polito it>,
    "Michael Richardson" <mcr () sandelman ottawa on ca>
References: <0a6f01c46b8b$24f83910$0a0beda9@ISKIATOR> <23D123BA-DC32-11D8-ADC9-000A958097E4 () alum mit edu>
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
Resent-To: tcpdump-workers () lists tcpdump org
Resent-Date: Sun, 25 Jul 2004 02:46:51 +0300
Resent-Message-ID: <1846.1090712811 () marajade sandelman ottawa on ca>
Resent-From: Michael Richardson <mcr () marajade sandelman ottawa on ca>

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" <guy () alum mit edu>
To: "Loris Degioanni" <ldegioanni () ucdavis edu>
Cc: "Fulvio Risso" <fulvio.risso () polito it>; "Gianluca Varenni"
<gianluca.varenni () polito it>; "Michael Richardson"
<mcr () sandelman ottawa on ca>
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.

Current thread:

[tcpdump-workers] Michael Richardson (Jul 26)
- <Possible follow-ups>
- Re: [tcpdump-workers] torsten (Sep 06)
  - Re: [tcpdump-workers] Michael Richardson (Sep 07)