Oops, sorry about that. I re-read your original post I missed that paragraph. Staring at those damned tcpdumps all day made me cross-eyed not to mention the headache.
Thanks for your help. ""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=49693&t=49535 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
