Evans, TJ wrote: > > 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. ? >
I don't think Host B is that smart actually. It doesn't know or care if its ACK got there. It doesn't try to figure out why it's getting a duplicate. Instead, it just does its normal job of recognizing and dropping the duplicate. On the other hand, a troublehsooter (as in a human), should recognize the situation you describe. This comes up rather often. You'll be looking at a protocol analyzer, for example, and you'll see that data got ACKed but that the sending host is sending it again anway. What you have to realize is that just because you see the ACK on the analzyer doesn't mean that the host saw it. The ACK got dropped somwehere en route to the host or possibly at the host. Then you start your "troubleshooting outward" approach, as Cisco calls it, to determine why ACKs are getting dropped. Priscilla > > 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=49716&t=49535 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
