On Tue, Jan 23, 2001 at 02:56:29PM -0800, Mike Schwartz wrote: > my apologies if this is the wrong place to send this. I didn't see > anywhere else to submit bug reports on http://www.tcpdump.org/ The man page says Please send problems, bugs, questions, desirable enhancements, etc. to: [EMAIL PROTECTED] so this is the right place to send this. > I notice that when I record a tcpdump 3.61 using 'tcpdump -w ...' and then > try to read it back using 'tcpdump -r' the following strange thing happens: > > if I read the file in using 'tcpdump -r' the sequence numbers on tcp > packets are one off from the sequence numbers when I read the file using > 'tcpdump -r src hostname'. Here's an example: > > % tcpdump -w t.o tcp and port 5001 & > % ttcp -t -s tuesday > % (kill tcpdump) > % tcpdump -r t.o | fgrep 15:37:40.281973 > 15:37:40.281973 monday.1120 > tuesday.5001: P 46337:47785(1448) ack 1 win > 39062 <nop,nop,timestamp 102779314 102780069> (DF) > % tcpdump -r t.o src monday | fgrep 15:37:40.281973 > 15:37:40.281973 monday.1120 > tuesday.5001: P 46336:47784(1448) ack 1 win > 39062 <nop,nop,timestamp 102779314 102780069> (DF) > > As you can see, the start and end sequence numbers reported are one off > from each other when I specify a src filter than when I don't specify one. > > Anyone else seen this, Yes. > and if so, is there a bugfix for it? The problem is in the code to find the initial sequence number. It looks only at frames with ACK set, and accepts either a TCP packet that doesn't belong to a conversation it's seen already, or a frame with SYN set, as the first frame. If it sees the full 3-way handshake, this means that the SYN+ACK frame, i.e. the second frame of the 3-way handshake, will be the one from which it gets the sequence numbers. In that frame, the ACK is the sequence number of the initial SYN frame, plus 1, so it subtracts 1 to get the initial sequence number from the machine that sent the initial SYN, and gets the initial sequence number of the other machine from that frame. 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. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
