lwIP - A Lightweight TCP/IP stack - Bugs: bug #27209, tcp_input discards frames even...
You are not allowed to post comments on this tracker with your current authentication level.
bug #27209: tcp_input discards frames even though they are within the announced window
Submitter: | Åke Rehnman <rehnmaak> | ||
Submitted: | Sun 09 Aug 2009 02:25:24 PM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | Fixed |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | CVS Head |
Jump to the original submission
Wed 12 Aug 2009 08:37:07 AM UTC, comment #23: |
Kieran Mansley <kieranm> |
Tue 11 Aug 2009 09:57:53 PM UTC, comment #22: Ok, I tested the patch and it seem to work as expected. Even though windows xp is overrunning our window lwip just discards the bytes outside the window. After that a zero window is advertised.
|
Åke Rehnman <rehnmaak> |
Tue 11 Aug 2009 02:30:49 PM UTC, comment #21: OK, I'll make those changes to my copy, and yes, it implements solution (2) |
Kieran Mansley <kieranm> |
Tue 11 Aug 2009 02:11:21 PM UTC, comment #20: Reading the patch, I think we can drop the second "if (TCPH_FLAGS(inseg.tcphdr) & TCP_FIN)" (inside the "else if (TCP_SEQ_LEQ(pcb->ooseq->tcphdr->seqno, seqno + tcplen))" block) since the FIN flag has already been checked above.
|
Simon Goldschmidt <goldsimon> |
Tue 11 Aug 2009 01:51:47 PM UTC, comment #19: Updated patch to correctly handle FIN that gets trimmed from the packet. This has turned out to be a much larger change than I first imagined, so I would welcome testing and code review, particularly as we're so close to the next release. |
Kieran Mansley <kieranm> |
Tue 11 Aug 2009 09:34:59 AM UTC, comment #18: The number of ACKs sent shouldn't have any effect. The other end might use this to increase their idea of the congestion window, but the receive window is specified by the values in the packet headers not the number of packets. I suppose that without the extra ACKs the sender retains a small congestion window and so doesn't send the frame that overruns the receive window.
|
Kieran Mansley <kieranm> |
Tue 11 Aug 2009 08:59:52 AM UTC, comment #17: I don't have the rest of that capture. But I could make a new one later tonight.
|
Åke Rehnman <rehnmaak> |
Tue 11 Aug 2009 08:49:29 AM UTC, comment #16: OK, so I agree that it looks like the other end is over-running the advertised window in frame 25 of that capture, and this in turn will cause us to incorrectly handle the value of rcv_wnd causing it to wrap.
|
Kieran Mansley <kieranm> |
Tue 11 Aug 2009 08:39:46 AM UTC, comment #15: sorry - my fault, got it now |
Kieran Mansley <kieranm> |
Tue 11 Aug 2009 08:37:29 AM UTC, comment #14: I can't open the pcap file: wireshark thinks it is invalid. |
Kieran Mansley <kieranm> |
Mon 10 Aug 2009 05:39:51 PM UTC, comment #13: Can someone have a look at the latest capture.
|
Åke Rehnman <rehnmaak> |
Mon 10 Aug 2009 11:57:03 AM UTC, comment #12:
|
Simon Goldschmidt <goldsimon> |
Mon 10 Aug 2009 11:41:30 AM UTC, comment #11: I've looked in the packet capture and don't see anything going outside the window. It goes right up to the right window edge, but doesn't exceed it. |
Kieran Mansley <kieranm> |
Mon 10 Aug 2009 11:35:14 AM UTC, comment #10: In that case it is probably something wrong where the out-of-order or retansmission seqments are handled. Because this problem only arises when I have lost frames at link level. |
Åke Rehnman <rehnmaak> |
Mon 10 Aug 2009 11:32:31 AM UTC, comment #9: Ultimately there are two possible solutions to this:
|
Kieran Mansley <kieranm> |
Mon 10 Aug 2009 11:21:00 AM UTC, comment #8: This suggests that either tcp_recved() is being called inappropriately, or tcp_wnd is not being decremented correctly earlier in the process of receiving a packet.
|
Kieran Mansley <kieranm> |
Mon 10 Aug 2009 11:18:04 AM UTC, comment #7:
|
Simon Goldschmidt <goldsimon> |
Mon 10 Aug 2009 11:12:10 AM UTC, comment #6: My TCP_WND is 65535.
|
Åke Rehnman <rehnmaak> |
Mon 10 Aug 2009 11:03:46 AM UTC, comment #5: What value of TCP_WND are you using?
|
Kieran Mansley <kieranm> |
Mon 10 Aug 2009 10:44:24 AM UTC, comment #4: Thanks for spotting this, I'll take a look. |
Kieran Mansley <kieranm> |
Sun 09 Aug 2009 10:36:56 PM UTC, comment #3: I've found the problem. In tcp_recved in tcp.c it is possible for the pcb->rcv_wnd to overflow if TCP_WND is large enough. I suggest the calculation should be done with u32_t and then checked if it is > TCP_WND.
|
Åke Rehnman <rehnmaak> |
Sun 09 Aug 2009 09:00:36 PM UTC, comment #2: The problem is trying to print a lot of info on a slow serial line is going to make us loose a lot of packets. Even so I made a capture and a log file. Only the lines when rcv_wnd < rcv_ann_wnd are printed.
|
Åke Rehnman <rehnmaak> |
Sun 09 Aug 2009 08:00:34 PM UTC, comment #1: After reading the code, I think it's quite odd that rcv_ann_wnd is grater than rcv_wnd. I would have expected it to be equal or less than rcv_wnd.
|
Simon Goldschmidt <goldsimon> |
Sun 09 Aug 2009 02:25:24 PM UTC, original submission:
tcp_input discards frames if they are outside pcb->rcv_nxt + pcb->rcv_wnd - 1.
|
Åke Rehnman <rehnmaak> |
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 10 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2009-08-12 | kieranm | Status | None | Fixed | |
Open/Closed | Open | Closed | |||
2009-08-11 | kieranm | Attached File | - | Added bug27209, #18554 | |
2009-08-11 | kieranm | Attached File | - | Added bug27209, #18553 | |
2009-08-10 | rehnmaak | Attached File | - | Added rcv_wnd_bug2.pcap, #18552 | |
2009-08-10 | kieranm | Planned Release | 1.3.1 | ||
2009-08-09 | rehnmaak | Attached File | - | Added rcv_wnd_bug1.pcap, #18549 | |
Attached File | - | Added session.log, #18550 | |||
2009-08-09 | rehnmaak | Attached File | - | Added session.txt, #18544 | |
Attached File | - | Added rcv_wnd_bug.txt, #18543 |
Powered by Savane 3.13-02a9.
Corresponding source code
Checked in, thanks for reporting and testing.
Microsoft may have made a mistake, or just tried to do things differently intentionally. The windows stack is not very conformant to the standards, but usually gets away with it.