lwIP - A Lightweight TCP/IP stack - Bugs: bug #34517, persist timer is started although...
You are not allowed to post comments on this tracker with your current authentication level.
bug #34517: persist timer is started although no zero window is received
Submitter: | Simon Goldschmidt <goldsimon> | ||
Submitted: | Mon 10 Oct 2011 07:50:11 AM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | None | Status: | Fixed |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | CVS Head |
Jump to the original submission
Fri 04 Nov 2016 06:42:38 PM UTC, comment #9: |
Joel Cunningham <jcunningham> |
Tue 01 Nov 2016 08:39:05 PM UTC, comment #8: Simon,
|
Joel Cunningham <jcunningham> |
Fri 14 Oct 2011 05:24:01 PM UTC, comment #7: Yeah, I also thought about that. However, we have another bug for that, which I regard mandatory for 1.4.1 - although I do not have a plan how to implement it. |
Simon Goldschmidt <goldsimon> |
Fri 14 Oct 2011 03:27:47 PM UTC, comment #6: Given that (if I remember correctly) we treat a window that is smaller than an MSS as a zero window so we don't have to split packets, is there a risk here that we could be prevented from sending due to the window being small (effectively a zero window) but we won't have started the persist timer as the window is not actually zero? |
Kieran Mansley <kieranm> |
Thu 13 Oct 2011 07:26:47 PM UTC, comment #5: Fixed by starting the persist timer when a zero window is received, not when we have more data queued for sending than fits into the window. |
Simon Goldschmidt <goldsimon> |
Thu 13 Oct 2011 07:23:20 PM UTC, comment #4: Updated summary: the actual bug is that the persist timer is started when we think the window is zero, not when we actually received a zero window. |
Simon Goldschmidt <goldsimon> |
Tue 11 Oct 2011 06:03:08 AM UTC, comment #3: Having had another look at this, I think that our condition when to start the persist timer is somewhat insecure. TCP/IP Illustrated (and other sources) say the persist timer should be started when we receive a zero-window announcement. However, we start it when we have more data to send than the window allows.
|
Simon Goldschmidt <goldsimon> |
Mon 10 Oct 2011 09:04:35 AM UTC, comment #2: We have implemented both: if tehre is already-sent (unacked) data, we send that. If not, we send 1 out-of-window byte.
|
Simon Goldschmidt <goldsimon> |
Mon 10 Oct 2011 08:21:00 AM UTC, comment #1: I think you are correct that the RTO mechanism will discover lost acks when there is unacked data, and the persist (or zero-window) timer is there to discover lost acks when there is no unacked data.
|
Kieran Mansley <kieranm> |
Mon 10 Oct 2011 07:50:11 AM UTC, original submission:
Is it correct that the persist timer is started although there is unacked data? I thought that this timer is responsible to prevent losing ACKs that open the window and I would have assumed that in the case where the window is not 0, the normal RTO-timeout retransmission would take place.
|
Simon Goldschmidt <goldsimon> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 6 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2011-10-13 | goldsimon | Status | In Progress | Fixed | |
Open/Closed | Open | Closed | |||
2011-10-13 | goldsimon | Summary | persist timer is started although there is unacked data | persist timer is started although no zero window is received | |
2011-10-11 | goldsimon | Status | None | In Progress | |
Assigned to | None | goldsimon | |||
Planned Release | 1.4.1 |
Powered by Savane 3.13-02a9.
Corresponding source code
Opened bug #49533 to move the discussion of the identified bug, also provide a patch