sam sneed wrote: > > How does the other host know its a keepalive? I do not see any > keepalive > fields in the TCP packet, perhaps a TCP option?
The recipient host doesn't know that it's a keepalive. There's really no such thing according to the official TCP RFC (793). The recipient just knows that it's a byte to be ACKed. The keepalive behavior (such as resending the same byte over and over again) is controlled by the sending application. > I think I was more confused by how the sequence #'s are > incremented and > ack'd. I read in Stevens book > " Since every byte that is exchanged is numbered, the > acknowledgement number > contains the next sequence number that the sender of the > acknowledgement > expects to receive. This is therefore the sequence number plus > 1 of the last > successfully received byte of data." Yes. That's right. When you get a chance, study TCP behavior with an analyzer when using a protocol such as FTP or HTTP. Studying it with keepalives won't help you learn because they send either zero or just one byte, which confuses matters. > 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. > > The problem I'm trying to solve is a TCP connection that > unexpectedly > terminates. Supposedly the client can detect this and reconnect > to the > server but there are problems. Can you put an anzlyer on both sides? One where the client is and one where the server is? Maybe the server isn't seeing the keepalives or ACKs to the keepalives. I wish I could help more. It's sounds like your on the right track though. Priscilla > I started the keepalive thread > last week > related to the same issue. I thought our firewall may have > droppped the > connection from its state table after its timeout but this is > not the case > since it seems keepalives are sent every 30 seconds. > > 17:56:46.563514 O 192.168.133.21.5055 > 10.10.10.12.1617: P > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > 17:56:46.604328 I 10.10.10.12.1617 > 192.168.133.21.5055: . ack > 2653258021 > win 17520 (DF) > > 17:58:20.327090 O 192.168.133.21.5055 > 10.10.10.12.1617: P > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > 17:58:20.368296 I 10.10.10.12.1617 > 192.168.133.21.5055: . ack > 2653258021 > win 17520 (DF) > > 17:59:54.090651 O 192.168.133.21.5055 > 10.10.10.12.1617: P > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > 17:59:54.132170 I 10.10.10.12.1617 > 192.168.133.21.5055: . ack > 2653258021 > win 17520 (DF) > > ""Priscilla Oppenheimer"" wrote in > message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > sam sneed wrote: > > > > > > I have been troubleshooting a problem and have seen > something I > > > don't > > > understand. If host A sends data to host B and host B acks > the > > > data, isn't > > > host A supposed to increment its seq #. Here is an actual > > > tcpdump. Host A is > > > 192.168.133.21 and B is 10.10.10.12. > > > You'll notice host A is pushing 1 byte of data and Host B is > > > acking it, yet > > > host A's seq never increments. Is this normal? > > > > It sounds like Host A has gone into a keepalive mode. It > doesn't have any > > actual data to send, so it just sits there sending one byte > at a time. > > > > We had a long discussion about TCP keepalives last week > sometime. You > might > > want to check the archives. The TCP RFC (793) doesn't > actually mention > > keepalives. With ordinary TCP, when there's no data to send, > both sides > are > > silent. But a lot of implementations send keepalives, and the > host > > requirements RFC does say that's OK. (RFC 1122) > > > > Theoretically a host should just be able to send an empty TCP > segment with > > no data to implement the keepalive function. In that case, > there's no > reason > > to increment the sequence number as sequence numbers count > payload bytes. > > However, some older implementations based on 4.2 BSD UNIX do > not respond > if > > the keepalive contains no data, causing the sender to think > its partner > has > > died. > > > > Some systems instead send one garbage byte of data to elicit > an ACK. They > > purposely keep the sequence number the same so that the > garbage byte can't > > cause any harm. It's not the expected sequence number. It's a > sequence > > number that the receiver already received and ACKed, so the > byte is thrown > > away before being given to an application (although it is > ACKed by TCP.) > > > > Some implementations send a keepalive with no data and if no > response is > > received, switch over to the 4.2 BSD style and send a garbage > byte. > > > > Anyway, I doubt this is related to the problem you are > troubleshooting > since > > it's normal behavior. What is the problem? Can you tell us > more about it? > > Thanks. > > ________________________ > > > > Priscilla Oppenheimer > > http://www.priscilla.com > > > > > > > > > > 17:56:46.563514 O 192.168.133.21.5055 > 10.10.10.12.1617: P > > > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > > 17:56:46.604328 I 10.10.10.12.1617 > 192.168.133.21.5055: . > ack > > > 2653258021 > > > win 17520 (DF) > > > 17:58:20.327090 O 192.168.133.21.5055 > 10.10.10.12.1617: P > > > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > > 17:58:20.368296 I 10.10.10.12.1617 > 192.168.133.21.5055: . > ack > > > 2653258021 > > > win 17520 (DF) > > > 17:59:54.090651 O 192.168.133.21.5055 > 10.10.10.12.1617: P > > > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > > 17:59:54.132170 I 10.10.10.12.1617 > 192.168.133.21.5055: . > ack > > > 2653258021 > > > win 17520 (DF) > > > 18:01:27.854289 O 192.168.133.21.5055 > 10.10.10.12.1617: P > > > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > > 18:01:27.895254 I 10.10.10.12.1617 > 192.168.133.21.5055: . > ack > > > 2653258021 > > > win 17520 (DF) > > > 18:03:01.618100 O 192.168.133.21.5055 > 10.10.10.12.1617: P > > > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > > 18:03:01.658892 I 10.10.10.12.1617 > 192.168.133.21.5055: . > ack > > > 2653258021 > > > win 17520 (DF) > > > 18:04:35.381698 O 192.168.133.21.5055 > 10.10.10.12.1617: P > > > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > > 18:04:35.422538 I 10.10.10.12.1617 > 192.168.133.21.5055: . > ack > > > 2653258021 > > > win 17520 (DF) > > > 18:06:09.145358 O 192.168.133.21.5055 > 10.10.10.12.1617: P > > > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > > 18:06:09.186227 I 10.10.10.12.1617 > 192.168.133.21.5055: . > ack > > > 2653258021 > > > win 17520 (DF) > > > 18:07:42.909048 O 192.168.133.21.5055 > 10.10.10.12.1617: P > > > 2653258020:2653258021(1) ack 808512610 win 8760 (DF) > > > 18:07:42.949850 I 10.10.10.12.1617 > 192.168.133.21.5055: . > ack > > > 2653258021 > > > win 17520 (DF) > > > > > > thanks > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=49677&t=49535 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
