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

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
16226
accept rate: 0%

edited 10 Oct '13, 18:34


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.

permanent link

answered 11 Oct '13, 02:50

mrEEde2's gravatar image

mrEEde2
3364614
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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×752
×19

question asked: 10 Oct '13, 18:27

question was seen: 4,038 times

last updated: 13 Oct '13, 07:52

p​o​w​e​r​e​d by O​S​Q​A