Re: Printing of TCP flags seems incorrect

[grarpamp <grarpamp () gmail com>]

Hi. I think I've found this 'none' printf you speak of. However it
does not appear to be excercised from what I can tell. Not sure
about that.

However as this code is still in flux [unreleased] and possibly
amenable to the influence of sanity, I would like to suggest that
the flags field be kept letter consistant with the bitfield...

If I receive a packet with ALL bits set I'd like to see:

flags: [NCEUAPRSF]

If I receive a packet with NO bits set I'd like to see:

# in order of preference
flags: []     obvious
flags: [.]    may be easier to parse as a none indicator,
               looks like the flags are physically squashed

If I receive a packet with undefined bits set it may make sense to
print:

flags: [undef] no longer a bitfield

Though the utility of printing that case is pretty slim.

# struct tok tcp_flag_values[]
This seems to define what is currently printed. In keeping with rfc
793/3168/3540, it seems they should all use the first character of
the definition. Resulting in: NCEUAPRSF

So "." would change to "A", "W" would change to "C" and TH_NS would
be added as "N".

The word "none" seems to be used only if the flag value is not found
in the token. A better word for this case would be "undefined" or
"undef" as above.

Thank you for your consideration as to applying this update and
conforming the man page to same :-) Want a patch???

Note also: http://www.iana.org/assignments/tcp-header-flags
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.