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=49583&t=49535 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
