By default, tcpdump displays relative TCP sequence number, and then only print the sequence if it is different, e.g.:
Flags [S], seq 3968763826, ... ## first time we get the seq, absolute numbers
Flags [S.], seq 372087587, ack 3968763827, ... ## same here
Flags [.], ack 1, ... ## relative number from here, not displaying the seq
Flags [P.], seq 1:101, ack 1,... , length 100 ## now displaying the seq, because there are some data
Instead, ptcpdump displays this:
Flags [S], seq 3968763826, ... ## same
Flags [S.], seq 372087587, ack 3968763827, ... ## same
Flags [.], seq 3968763827, ack 372087588, ... ## absolute numbers, with the sew
Flags [P.], seq 3968763827:3968763927, ack 372087588,... , length 100 ## harder to read
That's quite useful to have relative numbers, and strip the seq when not incremented to easily follow the traffic, than having to deal with big numbers.
This is linked to tcpdump's -S / --absolute-tcp-sequence-numbers option.
But I understand it might not be trivial to implement as it requires the ability to track connections. It would be nice to have this, but I can live without it.
By default, tcpdump displays relative TCP sequence number, and then only print the sequence if it is different, e.g.:
Instead, ptcpdump displays this:
That's quite useful to have relative numbers, and strip the seq when not incremented to easily follow the traffic, than having to deal with big numbers.
This is linked to tcpdump's
-S/--absolute-tcp-sequence-numbersoption.But I understand it might not be trivial to implement as it requires the ability to track connections. It would be nice to have this, but I can live without it.