Re: text format stability

[Hannes Gredler <hannes () juniper net>]

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.