Re: text format stability

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

Hannes,

> does this break existing scripts ?
> most certainly: however we have not yet found out how to
> progress the software in terms of new protcols and multilayer
> encapsualation support (gre/l2tp/mpls) and still stay 100%
> downwards compatible;

You don't need to stay 100% compatible.  However, some of the current changes 
appear arbitrary, in that they do not make tcpdump easier to read for humans or 
easier to parse for scripts in the common case.  Please don't make arbitrary 
changes.  Unless there is a clear, unambiguous win for a new format *in the 
common case*, stick with the old.

For example, the current tcpdump CVS puts a comma "," after the TCP flags if 
"-v" is on.  And later fields are rearranged in order.  Why???  This does not 
help the format become more understandable or internally consistent, I can't see 
how it helps anything.  (It certainly has no bearling on gre/l2tp/mpls.)  I 
really think this was an arbitrary change, made simply because it was felt no 
one would notice.  My scripts noticed, many other scripts will too.  It would 
really suck if these kinds of arbitrary changes started leaking into non-"-v"; 
then you will really hear an avalanche of complaints.

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 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.

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.


> 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.


> 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?

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