Re: text format stability

[Eddie Kohler <kohler () cs ucla edu>]

Hannes,

These changes should not have been implemented globally, without some flag or 
option to preserve the old behavior.  Such a flag should be added.

> i am a believer that networking dissectors should print data in the order
> they arrive ... header information comes before ip adresses, right ?

No.  They arrive in the same header, the IP header is a unit.  It is better to 
print those fields in the order more sensible for humans and more familiar from 
decades of tcpdump practice.  (Again, I agree that other header information 
might belong closer to the IP addresses, rather than at the end of the line.)

The "normative reference for tcpdump output style" was, again, literally decades 
of practice.

My point in writing was to point out that there is a large audience of tcpdump 
users who process its output with scripts.  There are thousands of scripts out 
there that you have broken, not just mine.  You haven't heard from them yet 
because new tcpdump hasn't seen wide distribution.

I don't feel that tcpdump output should be frozen forever; some changes are 
appropriate.  But the changes I've seen have seemed indiscriminate.  Again, why 
put a comma after the TCP flags?  Why reorder the TCP fields relative to one 
another?  Why change the way 'cksum' is spelled?  Why print out the checksum 
when it's valid?  Why not leave the IP addresses at the beginning of the line? 
Abstract reasons, about the physical order, are not good enough.

Eddie


> 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;
>
>
>
> /hannes
> -
> 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.