Re: [lwip-devel] Lost segments in tcp_receive

[Åke Rehnman]

The other end is windows xp...

I did test to change it to rcv_ann_wnd-1 and it works as well as the 
64*TCP_MSS.

The thing is that this problem only shows when I'm loosing packets (I'm 
currently testing the microblaze port by removing every 1000'nd input 
packet). And when lwip does loose packets this way windows starts a flood of 
retransmissions and often grinds to total stall. And I did check the stats 
and I'm not running out of resources.

/Ake

----- Original Message ----- 
From: <address@hidden>
To: <address@hidden>
Sent: Sunday, August 09, 2009 11:37 AM
Subject: Re: [lwip-devel] Lost segments in tcp_receive


> 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