> > So using the example below (host A 192.168.133.21, B > > 10.10.10.12), A sends 1 > > byte of data, last successful sent byte is 2653258021, > > No, the last successful byte is 2653258020. That's Host A's sequence number. > Host A sends only one byte, the byte numbered 2653258020. > The analyer you're using (is it TCPdump?) doesn't do a good job of making > this clear. I think it's trying to help you see what the expected ACK should > be. Don't read the second number as the sequence number of the last byte > sent. You'll be off by one if you do that.
> A common mistake people make (and your analyzer may be making) is to add the > length of the data to the sequence number to get the sequence number of the > final byte of data in the segment. That's doesn't work. You're mixing apples > and oranges. Actually, you're mixing cardinal numbers (how many, length) > with ordinnal numbers (order, rank, sequence). You'll be off by one. I > explain this in detail in my new book, Troubleshooting Campus Networks, in > the TCP chapter. ;-) > > > shouldn't Host B ack > > (2653258021)+1 ? > > No, Host B's ACK should be 2653258021. Host B is saying I got 2653258020 and > I'm expecting 2653258021 next. Once again, I think your analyzer's method of > display is confusing. > Yes, the analyzer is tcpdump and now I understand the error in my intrepretation. There is still one thing bothering me. Host A is a sending a keepalive with 1 garbage as in my previous post 2653258020, B acks 2653258021 the next SN its expects to see. But in my example host A sends 2653258020 with 1 byte of garbage again. Wouldn't this look a duplicate or at least an out of sequence frame since host B is expecting 2653258021 and has already ack'd 2653258020? There are no other ID fields in the TCP header so how would it not ignore it as a duplicate frame when its [src IP dest IP] [src port dest port] and sequence #'s are identical? I imported the raw packets into Ethereal so I could see all fields, even the 1 byte of garbage data is the same (00 in hex) and the header checksum are equal. I hate to beat this to death, but this stuff is a science and based on RFC's, so it kills me not to be able to interpret this exactly and correctly. There should be no mysteries behind this stuff. After troubleshooting my network problem for awhile, I've become more interested in understanding the exact workings of TCP than solving the original problem. Thanks alot for your insight. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=49682&t=49535 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
