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

TCP persist timer and probe packet’s data

0

I have a doubt regarding the persist timer and the associated probe packets.

  1. Lets say the receiver has sent out an ACK with window set to 0.
  2. As a result, the sender starts its persist timer.
  3. Now, the receiver sends an ACK with window set to 1000 and lets assume this ACK is lost in transit.
  4. So, when the persist timer pops off, the sender sends a probe packet to the receiver with a random byte in the data field.

Now, what will happen at the receiver: Will it see the 1-byte as application data or is there any for the receiver to identify that this is a probe segment?

If the receiver assumes this to be application data, this might lead to consequences as the application might interpret the data in its own way.

asked 10 Oct '13, 18:27

hdnivara's gravatar image

hdnivara
16●2●2●6
accept rate: 0%

edited 10 Oct '13, 18:34

One Answer:

1

The 'garbage' data will be sent using an incorrect sequence number so the receiving tcp will discard the segment and not pass invalid data to the application.

answered 11 Oct '13, 02:50

mrEEde2's gravatar image

mrEEde2
336●4●6●14
accept rate: 20%

Thanks.

I've a follow-up question: How would TCP on the sender side inform the application that the receiver will not able to receive more data at this moment?

In other words, what will be the effect on the data that the sender application pushes on to TCP if the sender's TCP buffer is full due to the zero window ACK from receiver? i.e., sender's TCP buffer is full of application data which TCP couldn't send as the receiver has not advertised a non-zero window yet. Now, the sender's application pushes more data to TCP, which can't be accommodated in the buffer.

I had a quick look on send()' man page; the error code ENOBUFS will be returned to the application if the sender's TCP buffer is full.

"ENOBUFS The output queue for a network interface was full. This generally indicates that the interface has stopped sending, but may be caused by transient congestion. (Normally, this does not occur in Linux. Packets are just silently dropped when a device queue overflows.)"

So, in Linux, if a scenario like this should arise, the sending application will have no clue on what's going on and whatever data it sends, would be lost forever. Talk about reliability :)

(13 Oct '13, 07:52) hdnivara