Last week me and Huzaifa were doing some network packet analysis to figure out why connections were aborting sometimes. He was going through the packet dump using Wireshark, while I was trying to observe TCP hand-shake with tcpdump(8). We saw the weirdest thing tcpdump(8) does while displaying TCP flags. For a successful TCP hand-shake, client & server exchange 3 packets in the following order, with the said TCP flags set.
Client —-> SYN —-> Server
Client <—- SYN + ACK <—- Server
Client —-> ACK —-> Server
Now, an intuitive way to display these flags would be to show their initials, like: S=SYN, A=ACK, F=FIN, so on and so forth, isn’t it? Wireshark does it nicely. Even tcpdump(8) does the same, except for the ACKnowledgement flag. For an ACKnowledgement flag they show a dot(‘.’) instead, because a dot(‘.’) says it best, isn’t it? Funny part is, they don’t stop there, they have also documented it in the manual:
Flags are some combination of S (SYN), F (FIN), P (PUSH), R (RST),
U (URG), W (ECN CWR), E (ECN-Echo) or `.’ (ACK), or `none’
if no flags are set.
Why would they do such a thing is a deep mystery. I tried to get some insight by reporting an issue -> https://github.com/the-tcpdump-group/tcpdump/issues/319. But as expected, they don’t seem to know it either. Plus they are unwilling to change this behaviour. That must be because it’s been the default behaviour from dinosaur’s ages I guess.
In general, we attempt to avoid gratuitous changes in output like this.
We are out of options as well.. It was my intention that things like this
would come with a name change to pktdump. pktdump would use all the same
code, but have a different main(), which different (saner) options, and
So, a patch to change this, optionally by flag in ndo->ndo_NEWFLAG
would be welcome, but I don’t think we are going to change the default.