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
Return-Path: <gianluca.varenni () polito it> 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 <mcr () pophost sandelman ottawa on ca>; 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 <mcr () sandelman ottawa on ca>; 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: <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 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: 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)