lwIP - A Lightweight TCP/IP stack - Bugs: bug #34111, RST for ACK to listening pcb has...
You are not allowed to post comments on this tracker with your current authentication level.
bug #34111: RST for ACK to listening pcb has wrong seqno
Submitter: | Simon Goldschmidt <goldsimon> | ||
Submitted: | Wed 24 Aug 2011 09:03:55 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
Thu 01 Sep 2011 07:51:18 PM UTC, comment #10: |
Simon Goldschmidt <goldsimon> |
Thu 01 Sep 2011 07:38:37 PM UTC, comment #9: Regarding the timeout, I think it is there to prevent a DoS attack where the other end refuses to send a FIN, thus leaving the connection open, and so consuming resources on the server. This makes it particularly important in lwIP where the resources are by definition small. |
Kieran Mansley <kieranm> |
Thu 01 Sep 2011 07:09:03 PM UTC, comment #8: Fixed by correcting seqno in RST sent in tcp_listen_input.
|
Simon Goldschmidt <goldsimon> |
Thu 01 Sep 2011 06:50:52 PM UTC, comment #7: TCP RFC 793 says:
|
Simon Goldschmidt <goldsimon> |
Thu 01 Sep 2011 08:11:03 AM UTC, comment #6: The fix proposed in comment #3 works for me (tested with Sysinternals TcpView, the half open connections chance from close-wait to closed after receiving the RST with correct seqno).
|
Simon Goldschmidt <goldsimon> |
Tue 30 Aug 2011 06:44:22 PM UTC, comment #5: I'm perfectly OK with getting the RST to work. However, I just have been wondering about the timeout sinethe TCP RFC does not mention a timeout for FIN WAIT2.
|
Simon Goldschmidt <goldsimon> |
Tue 30 Aug 2011 03:16:53 PM UTC, comment #4: I think we're in agreement, and the suggested fix from comment #3 sounds about right to me. |
Kieran Mansley <kieranm> |
Tue 30 Aug 2011 03:13:32 PM UTC, comment #3: 1: The wrong seqno cause the peer end doesn't close connection succefully.
|
tao tang <opensms4> |
Tue 30 Aug 2011 12:37:08 PM UTC, comment #2: The RST packets have the wrong sequence number: they are one octet too large, and so are being ignored. Let's fix that, but leave the timeout as is. |
Kieran Mansley <kieranm> |
Tue 30 Aug 2011 12:31:53 PM UTC, comment #1: I think the interesting bit here is why doesn't the RST cause the other end to give up. There must be something wrong with it. |
Kieran Mansley <kieranm> |
Wed 24 Aug 2011 09:03:55 AM UTC, original submission:
I observed this while adding support for HTTP/1.1 persistent connections (not checked in, yet):
|
Simon Goldschmidt <goldsimon> |
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 7 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2011-09-01 | goldsimon | Status | In Progress | Fixed | |
Open/Closed | Open | Closed | |||
2011-09-01 | goldsimon | Status | Confirmed | In Progress | |
Summary | TCP_FIN_WAIT_TIMEOUT might be too small | RST for ACK to listening pcb has wrong seqno | |||
2011-09-01 | goldsimon | Status | None | Confirmed | |
Assigned to | None | goldsimon | |||
2011-08-24 | goldsimon | Attached File | - | Added lwIP_FIN_WAIT_TIMEOUT_is_too_small.pcap, #23855 |
Powered by Savane 3.13-caa5.
Corresponding source code
I agree that it's a nice feature for lwIP to have, I was just curious why firefox (running on windows) would trigger a RST in such a normal condition. Maybe I did something wrong in the httpd, after all...