Thank you for your quick response.
The thing I did not implement was the chained pbufs. I checked and implemented
this and now I receive all frames. In the example in my original email after
receiving frame 13 I now follow the pbuf->next, and the missing packets are
chained there. So I am now receiving all data in the right order.
The issue with forward ACK is AFAIK an indication to the client that it can
continue with sending the next frame, and no need to send frames between the
missing one (13) and the next one (21).
Again, thanks for your help!
On Fri, Feb 23, 2018 at 12:00:43PM +0100, Simon Goldschmidt wrote:
> Johan Borkhuis wrote:
> > [..]
> > I am missing data with the size of one TCP_WND-1, so 7 frames. The data was
> > transmitted over the line, but at one moment the internal buffers are full
> > and I
> > start seeing duplicate ACKs.
> What internal buffers are you talking about? lwIP pbufs or buffers in your
> POST processing?
> > [..]
> > Why are the packets between 13 and 20 not received by the HTTP server?
> A better question is: why is packet 21 ACKed before it is sent?
> That indicates there's something wrong.
> > Do I
> > need to set another callback to process the out-of-sequence packets or is
> > there another option that can be set to make sure the packets are passed to
> > the application?
> No. This should just work. Pbufs are passed in sequence to your application.
> You don't get a pbuf passed twice though: once it gets passed to your recv
> callback, you need to handle it or it is lost.
> Also, you have to watch out for chained pbufs. Especially, pbufs are chained
> after OOSEQ processing even if they aren't otherwise.
> lwip-users mailing list
lwip-users mailing list