On Tue, Dec 03, 2019 at 10:00:01PM +1000, David Gwynne wrote: > this is a significant reworking of tcpdump with a couple of goals > twisted together. > > it is becoming increasingly common to encapsulate protocols, leading > to situations where you have some kind of ip packet inside another > ip packet. i am arguing our current ip printing code sucks in this > situation because some of the information about ip headers is printed > AFTER the payload. when you have a few layers of IP floating around, > it is difficult to associate these values back to the relevant header. > even if you don't have multiple IP layers, a big payload makes it > hard for my brain to backtrack. to address this, the diff moves > printing ip header properties to the front of the ip payload printing. > to give them some context, i'm prefixing the ip and ip6 printing > with IPv4 and IPv6 respectively. in practice it looks like this: > > before: > > dlg@v445 tcpdump$ tcpdump -nr /home/dlg/tmp/ping.pcap > 16:31:18.836620 10.0.127.15 > 10.0.127.1: icmp: echo request [tos 0x20] [ttl > 1] > 16:31:18.837074 10.0.127.1 > 10.0.127.15: icmp: echo reply [tos 0x20] > dlg@v445 tcpdump$ tcpdump -nr /home/dlg/tmp/ping.pcap -v > 16:31:18.836620 10.0.127.15 > 10.0.127.1: icmp: echo request (id:b59f seq:0) > [icmp cksum ok] [tos 0x20] [ttl 1] (id 39958, len 84) > 16:31:18.837074 10.0.127.1 > 10.0.127.15: icmp: echo reply (id:b59f seq:0) > [icmp cksum ok] [tos 0x20] (ttl 255, id 36919, len 84) > > after: > > dlg@v445 tcpdump$ ./obj/tcpdump -nr /home/dlg/tmp/ping.pcap > 16:31:18.836620 IPv4 ttl 1 [tos 0x20] 10.0.127.15 > 10.0.127.1: icmp: echo > request > 16:31:18.837074 IPv4 [tos 0x20] 10.0.127.1 > 10.0.127.15: icmp: echo reply > dlg@v445 tcpdump$ ./obj/tcpdump -nr /home/dlg/tmp/ping.pcap -v > 16:31:18.836620 IPv4 ttl 1 [tos 0x20] (id 39958, len 84) 10.0.127.15 > > 10.0.127.1: icmp: echo request (id:b59f seq:0) [icmp cksum ok] > 16:31:18.837074 IPv4 ttl 255 [tos 0x20] (id 36919, len 84) 10.0.127.1 > > 10.0.127.15: icmp: echo reply (id:b59f seq:0) [icmp cksum ok] >
I think this is a reasonable start. I would prefer if the IP options "ttl 255 [tos 0x20] (id 36919, len 84)" would be encoded in a somewhat nicer fashion instead of this random collection of [] () and bare keywords. Similar for IPv6: "IPv6 hlim 52 [flowlabel 0x7ed4a] (len 57)" again the line is just hard to scan. I would suggest to just pack most of the headers into one group of (). IPv4 ttl 1 [tos 0x20] 10.0.127.15 > 10.0.127.1 would become IPv4 (ttl 1 tos 0x20) 10.0.127.15 > 10.0.127.1 and IPv4 ttl 1 [tos 0x20] (id 39958, len 84) 10.0.127.15 > 10.0.127.1 would become IPv4 (ttl 1 tos 0x20 id 39958 len 84) 10.0.127.15 > 10.0.127.1 Maybe add the commas if that is easy to do. -- :wq Claudio
