0

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.

Batuhan Zorlu
  • 3
  • 2

1 Answers1

0

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.

Nikita Kipriyanov
  • 10,947
  • 2
  • 24
  • 45
  • 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. – Batuhan Zorlu Jan 24 '23 at 19:13
  • 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. – Nikita Kipriyanov Jan 24 '23 at 19:18
  • 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? – Batuhan Zorlu Jan 25 '23 at 14:37
  • 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). – Nikita Kipriyanov Jan 26 '23 at 05:16