lwIP - A Lightweight TCP/IP stack - Bugs: bug #49631, Zero window and refused data...
You are not allowed to post comments on this tracker with your current authentication level.
bug #49631: Zero window and refused data problem
Submitter: | Dirk Ziegelmeier <dziegel> | ||
Submitted: | Thu 17 Nov 2016 09:09:16 AM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | Fixed |
Privacy: | Public | Assigned to: | jcunningham |
Open/Closed: | Closed | Planned Release: | 2.0.1 |
lwIP version: | git head |
Jump to the original submission
Fri 16 Dec 2016 04:09:38 PM UTC, comment #14: |
Joel Cunningham <jcunningham> |
Fri 16 Dec 2016 02:49:27 PM UTC, comment #13: I understood the problems with lwip<->lwip. However, I don't know how we could solve this without losing the congestion-like "throttling" feature implied with dropping incoming segments when we have refused_data (send last ACK when announced window is < MSS would fix this, but that would be strange).
|
Simon Goldschmidt <goldsimon> |
Fri 16 Dec 2016 12:08:48 AM UTC, comment #12: Updated patch to remove check against tcplen == 1. This will still only trigger on a data segment because of the above check for pcb->refused_data != NULL && tcplen > 0. This is correct so that we aren't sending an empty ACK in response to an ACK/window update from the remote TCP |
Joel Cunningham <jcunningham> |
Thu 15 Dec 2016 11:21:59 PM UTC, comment #11: I'm fine with that. I re-read RFC 793 and it doesn't specify that a zero window probe MUST only be 1 byte. I must have remembered incorrectly:
|
Joel Cunningham <jcunningham> |
Thu 15 Dec 2016 12:00:55 PM UTC, comment #10: This would be the last item for 2.0.1, which I'd like to release to start a phase of shorter bugfixing releases (2.0.0 is nearly 2 months old already, and there have been some more or less critical things done since then).
|
Simon Goldschmidt <goldsimon> |
Wed 14 Dec 2016 02:07:20 PM UTC, comment #9: Having thought about this, I think we can ignore tcplen and just send an empty ACK if rcv_ann_wnd is zero.
|
Simon Goldschmidt <goldsimon> |
Sat 10 Dec 2016 12:40:33 AM UTC, comment #8: I studied the tcp input path and the distance between the refused_data check and the check against receive window. Switching these two is going to be a much more involved and risky due to the amount of logic that separates the two checks.
|
Joel Cunningham <jcunningham> |
Thu 08 Dec 2016 11:31:16 PM UTC, comment #7: Yes, I think I can provide a patch that checks our announced window (instead of actual window) before accepting segments.
|
Joel Cunningham <jcunningham> |
Thu 08 Dec 2016 08:26:21 PM UTC, comment #6: After all, the problem stays the same, wheter we have refused_data or not: having it gets us one segment further and we'll have to ignore (not ACK) the next segment.
|
Simon Goldschmidt <goldsimon> |
Thu 08 Dec 2016 04:28:13 PM UTC, comment #5: If we did the proposed announced window check before the refused_data check, then it wouldn't matter whether refused_data was non-NULL or not because any zero window probe would be responded to with an ACK containing RCV.NEXT and then the data segment dropped. I was suggesting it as a smaller scope fix that addresses the standards violation.
|
Joel Cunningham <jcunningham> |
Tue 06 Dec 2016 01:28:54 PM UTC, comment #4:
|
Simon Goldschmidt <goldsimon> |
Mon 28 Nov 2016 06:12:12 PM UTC, comment #3: Simon,
|
Joel Cunningham <jcunningham> |
Thu 24 Nov 2016 08:23:25 AM UTC, comment #2: To sum it up in short, the correct behaviour would be:
|
Simon Goldschmidt <goldsimon> |
Wed 23 Nov 2016 08:27:46 PM UTC, comment #1: From Simon and I discussion in the attached email:
|
Joel Cunningham <jcunningham> |
Thu 17 Nov 2016 09:09:16 AM UTC, original submission:
|
Dirk Ziegelmeier <dziegel> |
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 |
---|---|---|---|---|---|
2016-12-16 | jcunningham | Status | None | Fixed | |
Open/Closed | Open | Closed | |||
2016-12-16 | jcunningham | Attached File | - | Added 0001-bug-49631-handle-zero-window-probe-and-refused_data.patch, #39245 | |
2016-12-10 | jcunningham | Attached File | - | Added 0001-First-pass-at-fixing-refused_data-with-zero-window-p.patch, #39191 | |
2016-12-09 | dziegel | Planned Release | None | 2.0.1 | |
2016-12-08 | goldsimon | Assigned to | goldsimon | jcunningham |
Powered by Savane 3.13-758e.
Corresponding source code
Latest patch commit in cceea73c3f32f433f3d6b5c8212a8ca1f06cddab
I agree that supporting the the lwip <-> lwip case we start down a path of adding strange, stack dependent checks.