Is it also relevant/correct that in a case like this, just under normal TCP operation, HostB would assumes HostA did not receive the ACK, which resulted in HostA restransmitting the original packet ... and HostB re-ACK'ing it ... etc. etc. ?
Thanks! TJ -----Original Message----- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 2:12 PM To: [EMAIL PROTECTED] Subject: Re: TCP sequence numbers question [7:49535] I already explained that, as does Stevens. (You have his book, I think. It's great.) The RFCs may not explain it. The creators or TCP don't approve of keeaplives. Anyway, the sender purposely keeps the sequence number the same when implementing the keepalive process. That causes the recipient to trash the garbage byte instead of giving it to the application. Remember there's an application running above all this (identified by the port number). The transport layer does not pass the garbage byte to the application because it appears to be a byte it already received. That's a basic TCP task. Priscilla sam sneed wrote: > > > > 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. ***************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter. ***************************************************************************** Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=49694&t=49535 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
