lwIP - A Lightweight TCP/IP stack - Bugs: bug #33962, TF_FIN not always set after FIN is...
You are not allowed to post comments on this tracker with your current authentication level.
bug #33962: TF_FIN not always set after FIN is sent
Submitter: | Cameron Gutman <aicom> | ||
Submitted: | Sun 07 Aug 2011 05:09:39 AM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | Fixed |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | CVS Head |
Mon 22 Aug 2011 04:57:55 PM UTC, comment #4: |
Simon Goldschmidt <goldsimon> |
Mon 22 Aug 2011 12:36:40 PM UTC, comment #3:
|
Stephane Lesage <slesage> |
Mon 22 Aug 2011 12:12:53 PM UTC, comment #2:
|
Simon Goldschmidt <goldsimon> |
Fri 19 Aug 2011 10:57:58 AM UTC, comment #1: Hi.
|
Stephane Lesage <slesage> |
Sun 07 Aug 2011 05:09:39 AM UTC, original submission:
The TF_FIN flag is not set in the PCB if the FIN is added to an existing segment in tcp_send_fin(). This causes a problem in tcp_output() where sending is stopped when it shouldn't be by the Nagle code. |
Cameron Gutman <aicom> |
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-08-22 | goldsimon | Status | Works For Me | Fixed | |
Open/Closed | Open | Closed | |||
2011-08-22 | goldsimon | Status | None | Works For Me | |
Assigned to | None | goldsimon | |||
2011-08-07 | aicom | Attached File | - | Added FIN-patch.diff, #23757 | |
Carbon-Copy | - | Added -email is unavailable- |
Powered by Savane 3.13-caa5.
Corresponding source code
Oh, right, sorry for messing that up. I saw it now from the mailing list, but the post here was a bit less detailed than that.
After all, I had three weeks to catch up on the list ;-)
Fixed by adding the proposed "pcb->flags |= TF_FIN;"
I regard this as a minor bug (it only influences throughput, does not corrupt anything, so no need to force a new release).