Re: [tcpdump-workers] bug when specifying filter to read a tcpdump file (written with -w)

[Mike Schwartz]

thanks for your explanation.  One other minor suggestion is to print a brief msg on stderr when you detect a situation (like you mention at the end of your note below) where you can't get the right relative seq numbers ("note: initial handshake packet(s) missing from a tcp conversation in this trace, so relative sequence numbers may be incorrect")
 - Mike

At 11:32 PM 1/23/01, Guy Harris wrote:

...
If it *doesn't* see the full 3-way handshake, but sees only the initial
SYN and the final ACK - for example, because you used a filter that
accepts only packets coming from the machine that sent the initial SYN,
as you did in your second example - the ACK frame, i.e.  the third frame
of the 3-way handshake, will be the one from which it gets the sequence
numbers.  In that one, the ACK is the sequence number of the SYN+ACK
frame, plus 1, and the sequence number is the sequence number of the
initial SYN, plus 1.  It subtracts 1 from the ACK, to get the right
sequence number for frames from the connected-to machine, but doesn't
subtract 1 from the sequence number, making the relative sequence number
of frames from the connecting machine off by 1 (too small by 1, as the
starting sequence number is too large by 1).

We could, in this case, subtract 1 from *both* sequence numbers if SYN
*isn't* set in the frame; if the frame isn't part of the 3-way
handshake, we aren't going to be able to get the right relative sequence
numbers in any case.