tcpdump mailing list archives

Re: text format stability


From: Hannes Gredler <hannes () juniper net>
Date: Sat, 26 Jun 2004 00:31:57 +0200

On Fri, Jun 25, 2004 at 02:21:24PM -0700, Christian Kreibich wrote:
| Hi,
| 
| On Fri, 2004-06-25 at 02:04, Hannes Gredler wrote:
| >
| > i am a believer that networking dissectors should print data in the order
| > they arrive ... header information comes before ip adresses, right ?
| > the IMHO bad bad practise of printing header information (old format)
| > at the end of the packet messed up multiline decoders and any decoder
| 
| just in case you really go forward with implementing configurable
| output, then by all means consider adding an option that allows
| disabling multiline output. It's a real pita.
| 
| Otherwise I'm with Eddie on this -- you really don't want to change the
| tcpdump textual output without a good reason and a *big* warning sign
| after everbody finally got their regexes to do what they wanted :)
| 
| A few months ago this list saw a discussion of the future capture file
| format (what's the latest on that btw), and back then I suggested in
| context of Jefferson's XML proposal that while I personally think an XML
| capture format is not the right idea, an XML based tcpdump output would
| be great in the long term -- it would certainly eliminate a lot of
| parsing ambiguity.

i concur ... nice TLV oriented binary encoding is good for .pcap storage
however for further processing an XML output maybe ideal; that way tcpdump
also could evolve to a "parsing middleware" fitting a nice niche
between full-featured decoders like ethereal;

/hannes
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Current thread: