tcpdump mailing list archives
Re: text format stability
From: Hannes Gredler <hannes () juniper net>
Date: Fri, 25 Jun 2004 11:04:05 +0200
On Thu, Jun 24, 2004 at 10:56:09AM -0700, Eddie Kohler wrote: eddie, [ ... ] | Similarly, it seems a mistake to put IP header information (tos, ttl, id, | offset, flags, proto, length) before the addresses. This changes | longstanding tcpdump practice and makes the output *less* readable, since | the addresses are generally more important to humans than this info. We | could argue about whether this header info belonged at the end of each line | (where tcpdump formerly put it), or immediately after the addresses. But | putting it *before* the addresses is too much. 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 that has to display a hierarchy -> just remember the output mess that the GRE/IP decoder creates and the difficulty for humans to spot IP[n] TTL where N is a level of tunnels; - and there is quite a user base [FW-guys] that are interested in that level of information; | I was also a little put out by the fact that in the last tcpdump release -v | output said "proto 6", and now it says "proto: TCP (6)". There is great | value in picking a format and sticking with it. I am afraid that these | tinkerings will never stop. host-indep. proto name resolution was on the wishlist long time; nevermind, we are pretty much done for the main decoders [MPLS,IP,IP6,Ether,PPP,CHDLC,TCP] i am not yet done with UDP, FR, IPSec etc. | It would seem to me that the best approach here would be to design a new | format that applied *only in those cases where it was required*: | gre/l2tp/mpls tunneling. And of course it doesn't matter how new protocols | are printed, there are no backwards compatibility issues. i strongly have to disagree here: the main problem in the past was that we had no output consistiency across the dissectors ... the recent work aligned the style and readability to a common format which we should stick to ... agreed; maybe it would be also a good idea to publish a output guide to make things uniform right from the beginning when people work on new dissectors; | >my take is that until we change tcpdump output to | >an optional machine-parsable output (could be XML, | >could be anything else) we cannot solve this issue | >fundamentally; | | You cannot *solve* it, but your current course makes life much harder for | the installed base of tcpdump users. apologies if i created discomfort ... we have been on this course for 18 months now and generally the feedback on readability of tcpdump outputs was a positive one; | >i had some offline discussion with michael and our current | >understanding is that we need to progress tcpdump which today just | >prints frames to a new structure that builds protocol trees; | > | >on the frame end we finally render the frame to a format | >that human|machine prcessors can understand; i.e. decouple | >protocol dissection from output rendering; | > | >it would be interesting to know from the community if | >such an effort would be seen worthwile; | > | >opinions ? | | I don't see how this internal restructuring would affect tcpdump users. | | In summary, I hope I can convince you to change "-v" text output back | towards the older format, for the common cases that most tcpdump users care | about. Think of it this way: until very recently, users could run "tcpdump | -v" and get the same output they would expect from Stevens' books. The | wire formats have not changed. Why should tcpdump's output? the stevens book is a good source for learning about ip however not a normative ref. for tcpdump output style; wrt change / why ?: for the above mentioned reasons: old-tcpdump was non-uniform, misordered, non-hierarchy capable and we felt to progress it further rather than keeping it dormant; i may kindly ask to adapt your scripts b/c i do not want to backout the changes made; also i can reassure that the mentioned dissectors are relatively stable i.e. it is unlikely that there will be further changes here; /hannes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Current thread:
- text format stability Eddie Kohler (Jun 23)
- Re: text format stability Hannes Gredler (Jun 24)
- Re: text format stability Eddie Kohler (Jun 24)
- Re: text format stability Jefferson Ogata (Jun 24)
- Re: text format stability Eddie Kohler (Jun 24)
- Re: text format stability Hannes Gredler (Jun 25)
- Re: text format stability Michael Richardson (Jun 25)
- Re: text format stability Eddie Kohler (Jun 25)
- Re: text format stability Hannes Gredler (Jun 25)
- Re: text format stability Eddie Kohler (Jun 25)
- Re: text format stability Eddie Kohler (Jun 24)
- Re: text format stability Michael Richardson (Jun 30)
- Re: text format stability Hannes Gredler (Jun 24)
- Re: text format stability Eddie Kohler (Jun 25)
- Re: text format stability sthaug (Jun 25)
- Re: text format stability Christian Kreibich (Jun 25)
- Re: text format stability Hannes Gredler (Jun 25)
- Re: text format stability Guy Harris (Jun 25)