I would be interested in why the other end overruns the receive window.
Which operating system is the other side running? If it's windows or linux,
I'd rather think of a bug in lwIP...
I'm not that familiar with the rcv_ann_wnd code (I think it was added
after 1.3.0 only), but since I think it's the window we announced to the
other side, we should allow all packets in the window we announced.
Could you check if using rcv_ann_wnd instead of rcv_wnd ( -> "pcb->rcv_nxt
+ pcb->rcv_ann_wnd - 1") fixes the window overrun?
Simon
Åke Rehnman wrote:
I have a whole lot of lost segements in tcp_receive in tcp_in.c. I've
tried to figure it out why the other end of the ethernet cable does
overrun our window. What I have discovered is that the rcv_ann_wnd is
sometimes much larger than rcv_wnd. If this is because of poor window
management in lwip or if it is just because there can be quite large
latencies when the bit rate is high I don't know.
Anyway just because of the other end is a bad boy doesn't mean that we
have to trash the frame if it's outside our window. I made a small hack
where the tcp_receive function dosen't reject the frame if it's greater
than pcb->rcv_nxt + pcb->rcv_wnd - 1. (I just added 64*TCP_MSS to the
right edge in the compare).
Is this something we could change in some future release? Any comments?
/Ake
------------------------------------------------------------------------
_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel
_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel