This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Why do TCP clients send packets with no data?

1

After the TCP connection between server and client establishes, I'm seeing a lot of TCP packets with no length like the one below, where 172.16.80.65 is the client and 172.16.178.77 is the server:

70  1.064245    172.16.80.65    172.16.178.77   TCP cvspserver > 60000 [ACK] Seq=1112 Ack=33028 Win=65535 Len=0
detail:Frame 74 (60 bytes on wire, 60 bytes captured)

I determined the 60 bytes are from:

20 bytes TCP header + 20 bytes IP header + 14 bytes Ethernet + 6 bytes Trailer

Do these packets belong to the TCP/IP protocol? If so, what's their purpose? and why are they sent so frequently? (perhaps to maintain or check the connection between server and clients)

UPDATE:

Hi,you guys should have a look on this picture:(server 80.77 is linux,client 80.65 is WindowsXp) (1)surely,No.1,No.2 and No.3 mean TCP three-way handshaking. (2)No.4 means a message from my client application.(just like a login message req) (3)Focus on No.5 and No.7,actually my server application doesn't send these packets and only send No.6 to reply the No.4's login req. (4)Focus on No.14 and No.18,I also have no idea about these kind of packets that came from client 80.65. So,Is there any veteran could give me an understandable answer.Too many thanks! alt text

This question is marked "community wiki".

asked 12 Jun '12, 20:12

waterjacky's gravatar image

waterjacky
1224
accept rate: 0%

edited 13 Jun '12, 20:23

helloworld's gravatar image

helloworld
3.1k42041


2 Answers:

2

Yes, this is a TCP/IP packet that has to do with maintaining the connection. "[ACK]" indicates that this packet has the ACK bit set. 172.16.80.65 is acknowledging data from 172.16.178.77. The Ack number of 33028 means that it has successfully received data through byte 33027, and it expects byte 33028 next. The data length is zero because 192.16.80.65 is only acknowledging data; it is not sending any data.

There are other circumstances in which a system will send TCP packets with zero length. You will need a TCP/IP reference. The TCP/IP Guide is a little awkward to use, but it's online and free.

answered 12 Jun '12, 22:33

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

Have a look on my answer,there are some concrete discription, thanks.

(13 Jun '12, 19:53) waterjacky

0

Packets with an ACK flag and 0 size can be TCP Keepalive packets. So (usually) no need to worry about those.

See RFC 1122 - 4.2.3.6 TCP Keep-Alives

Regards
Kurt

answered 13 Jun '12, 01:46

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 13 Jun '12, 03:37

If the packet is a normal ACK or used as a Keep-Alive can be determined by looking at the SEQ of the packet:

Such a segment generally contains SEG.SEQ = SND.NXT-1 and
may or may not contain one garbage octet of data.

(from the RFC)

(13 Jun '12, 04:10) SYN-bit ♦♦

You're right. However, the TCP Keep-Alive section contains a lot "could", "should", "some", "however" and "unfortunately".

Especially the section about the mentioned SEQ number starts with

Some TCP implementations , however, have included a keep-alive mechanism.

I would not bet on that SEQ calculation mechanism ;-)

(13 Jun '12, 04:22) Kurt Knochner ♦

It's always nice to discuss RFC interpretations, as they do leave room for discussion even though they have been formulated carefully.

The way I read that part of the RFC is that there is no Keep-Alive implementation in the TCP protocol, but some systems have implemented a Keep-Alive mechanism by sending a packet with SEG.SEQ = SND.NXT-1 forcing the other side to send an ACK. However, some implementations do not send the ACK for an empty packet, so that one garbage octet (as it is outside the RCV window) is used to force the ACK from the other side.

This is in line with what I have seen live

(13 Jun '12, 04:35) SYN-bit ♦♦

I have not seen any systems sending out ACK's by themselves with SEG.SEQ = SND.NXT as a Kaap-Alive mechanism. Have you? Do you have a trace you can share? It is always nice to broaden one's mind :-)

Funny though, I was at a customer this week who saw 15-20% retransmissions on a windows system (based on the TCP stats of the interface).

A little trace showed Keep-Alive packets. So Windows 2008R2 is not able to distinguish between a retransmission and a Keep-Alive (with one octet garbage).

(13 Jun '12, 04:40) SYN-bit ♦♦

Have you? Do you have a trace you can share? It is always nice to broaden one's mind :-)

I'm searching one :-) Hold on ....

(13 Jun '12, 04:42) Kurt Knochner ♦

Have a look on my answer,there are some concrete discription, thanks.

(13 Jun '12, 19:52) waterjacky

RFC 1122 specifies that keep-alive packets must only be sent when a certain (undefined) interval has passed. In the graphic, it appears that the time column is formatted for seconds since beginning of capture, in which case all zero-length ACKs from the client are seen within just over 1 ms of the preceding packet, and all zero-length ACKs from the server are seen within well under 1 ms of the preceding packet. I'd say these are normal ACKs, not keep-alives. It's extremely unlikely that a TCP implementation considers the connection "idle" after less than 1 ms.

(15 Jun '12, 13:26) Jim Aragon
showing 5 of 7 show 2 more comments