Score:0

Continuous [ACK]Packets Without any Response From Receiver

gl flag

Our application sends some data to one of our devices via TCP/IP, However communication in between not working as it should be.Because TCP/IP is bidirectional, so if one side sends data to other, other sends ACK flag.

CAPTURE

As it seen in the capture, IP:192.168.0.43 sends bunch of [ACK]Packets with 1460 byte size, but there is no response from 192.168.0.103. Even though there is no answer, IP:192.168.0.43 behaves like, it gets the response and increases the Sequence number. While there is no TCP Retransmission error, I assume communication works properly. But how does it work like this ?

thanks.

Score:0
za flag

No, all right. Large amount of data is transmitted from 192.168.0.43 to 192.168.0.103. It sends 1460-octet packets (that's MSS in that direction). There is no reverse stream data, so it constantly acknowledges it received octet 1.

In the reverse direction we see zero-length packets with increasing acknowledged octet number, and it increases steadily. 192.168.0.103 only confirms reception of the stream, but doesn't itself send anything.

Notice that the receiver doesn't send an individual acknowledgement for every packet. In TCP not the packet reception is acknowledged, but the octet reception. Once sender has "ack 42463" it knows all octets up to this one were received, no matter how they were segmented — was that a single big packet of 42463 bytes or 40 packets of around 1 kbyte. And, knowing that, receiver is free to benefit from a wide window and send acknowledgements every few packets. In this case it only sends ack approximately every five packets, acknowledging the reception of all the data in them at once.

Batuhan Zorlu avatar
gl flag
Thanks! makes sense now. But when one side sends a packet, does it need to have [PSH,ACK] flags rather than just [ACK]? Because in my case there are [ACK] flags while sending data. Sometimes it sends with [PSH,ACK] flags.
Nikita Kipriyanov avatar
za flag
PSH demands to send answer immediately. If the OS on the other side has something buffered, it will be dumped into the network, also it should make it to ACKnowledge the reception of all the data up to and including the octets in the PSH packets. Notice there always is a reverse ACK after the PSH, and PSH itself is not filled up to MSS. It's the way of the synchronization over TCP. Probably, there are application-level message boundaries in those packets or something like this; that's sending *application* is what asked the OS to add PSH flag.
Batuhan Zorlu avatar
gl flag
Thanks again for clear explanation. There is just one question left in my mind. When you said "the data will be dumped into the network", you meant dumped into the router or it is still on the sender side, while receiver does not acknowledge us, cant be the one all the data dumped right?
Nikita Kipriyanov avatar
za flag
Kernel will not wait until the buffer fills up to MSS and send anything that it has buffered immediately, resulting in less-than-MSS TCP segment. Which is fine, but less efficient, but if you just completed an application-level message and want it to be delivered now, it's inevitable, not all messages are comprised of whole number of MSS octets. Sometimes, messages are only few bytes each (think keystrokes on SSH; try to capture its traffic and observe how it uses PSH).
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.