tcpdump mailing list archives
Re: Fw: new file format
From: "Gianluca Varenni" <gianluca.varenni () polito it>
Date: Thu, 29 Jul 2004 13:13:05 -0700
Hi. I haven't seen any reply to Fulvio's proposal about removing the byte order magic and using the string "\r\n\r\x1A". Personally, I prefer my original proposal of leaving the byte order magic and the block type "\r\n\n\r" (just because we have 8 bytes to check if the file is correct and understand its byte order). Can we decide what is the final block type for the section header block? Have a nice day GV ----- Original Message ----- From: "Gianluca Varenni" <gianluca.varenni () polito it> To: <tcpdump-workers () tcpdump org> Sent: Monday, July 26, 2004 5:04 PM Subject: [tcpdump-workers] Fw: new file format ----- Original Message ----- From: "Fulvio Risso" <fulvio.risso () polito it> To: "Gianluca Varenni" <gianluca.varenni () polito it>; "Guy Harris" <guy () alum mit edu> Cc: "Loris Degioanni" <ldegioanni () ucdavis edu>; "Michael Richardson" <mcr () sandelman ottawa on ca> Sent: Friday, July 23, 2004 11:22 PM Subject: RE: new file format I would like to propose the string "\r\n\r\x1A", so that: - correct byte order, correct ftp transfer ==> "\r\n\r\x1A" - correct byte order, wrong ftp UNIX to Win ==> "\r\n\n\r\" - correct byte order, wrong ftp Win to UNIX ==> "\n\r\x1A\?" - changed byte order, correct ftp transfer ==> "\x1A\r\n\r" - changed byte order, wrong ftp UNIX to Win ==> "\x1A\r\r\n" - changed byte order, wrong ftp Win to UNIX ==> "\x1A\n\r\?" If I'm not making any further mistake, this string should recognize both byte order and correct ascii transfer. Cheers, fulvio
-----Original Message----- From: Gianluca Varenni [mailto:gianluca.varenni () polito it] Sent: venerdì 23 luglio 2004 21.34 To: Guy Harris Cc: Loris Degioanni; Fulvio Risso; Michael Richardson Subject: Re: new file format ----- Original Message ----- From: "Guy Harris" <guy () alum mit edu> To: "Gianluca Varenni" <gianluca.varenni () polito it> Cc: "Loris Degioanni" <ldegioanni () ucdavis edu>; "Fulvio Risso" <fulvio.risso () polito it>; "Michael Richardson" <mcr () sandelman ottawa on ca> Sent: Friday, July 23, 2004 12:14 PM Subject: Re: new file formatOn Jul 23, 2004, at 11:57 AM, Gianluca Varenni wrote: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.Is there always only one way of converting between UN*X format and Windows format? Or could information be lost, even for this particular case, in a way that prevents it from being reclaimed?I don't know...One possibility would be to assume that if the byte-order magic appears within some number of bytes of the proper position the file was a valid dump file transferred in ASCII order. I suspect that, in a UN*X to Windows transfer, at most every \n would become a \r, so that'd meanNot sure about that.that the magic number would be at most 6 bytes after the correct position (if the block size *happened* to be 168430090, i.e. 0x0a0a0a0a, or \n\n\n\n) and, in a Windows to UN*X transfer, at most every \r would be deleted, so that'd mean that the magic number would be at most 6 bytes before the correct position (if the block size *happened* to be 218959117, i.e. 0x0d0d0d0d, or \r\r\r\r), so if the byte-order magic appears (in either byte order) in an offset between 2 (8-6) and 14 (8+6), assume the file was a valid file transferred in ASCII mode. I.e., don't bother trying to recover the block type and block size, just check for a byte-order magic in any of the places where it could possibly be.Neither I want to recover the file. I like the solution you propose: if the \r\n\n\r is not found at the beginning of the file, we look for the magic number from byte 2 to byte 14 of the file. If we find, we report an "ASCII format conversion mismatch" error (or something like that). I think this is the solution to the problem. Have a nice day GV(We'd do the same with subsequent section header blocks, and say "sorry, some part of this file was transferred in ASCII mode" or "somebody concatenated to a file another file transferred in ASCII mode".)
- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Current thread:
- Re: new file format Fulvio Risso (Jul 26)
- <Possible follow-ups>
- Re: new file format Guy Harris (Jul 26)
- Fw: new file format Gianluca Varenni (Jul 26)
- Re: Fw: new file format Gianluca Varenni (Jul 29)
- Re: Fw: new file format Fulvio Risso (Jul 30)
- Re: Fw: new file format Gianluca Varenni (Jul 30)
- Re: Fw: new file format Gianluca Varenni (Jul 29)
- Fw: new file format Gianluca Varenni (Jul 26)