lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Re: [lwip] TCP ack segment versus OOSEQ handling


From: Kieran Mansley
Subject: [lwip-users] Re: [lwip] TCP ack segment versus OOSEQ handling
Date: Wed, 08 Jan 2003 23:17:06 -0000

On Thu, 8 Aug 2002, Andy Valencia wrote:
> We're seeing a problem with the OOSEQ code when a packet with no
> payload comes in.  Consider the case where:
>
>         if(inseg.p->tot_len > 0) {
>           pcb->recv_data = inseg.p;
>           /* Since this pbuf now is the responsibility of the
>              application, we delete our reference to it so that we won't
>              (mistakingly) deallocate it. */
>           inseg.p = NULL;
>         }
>
> has in fact a tot_len of 0, thus pcb->recv_data remains NULL.
>
> Now in the OOSEQ handling, the code sequence at:
>
>           if(cseg->p->tot_len > 0) {
>             /* Chain this pbuf onto the pbuf that we will pass to
>                the application. */
>             pbuf_chain(pcb->recv_data, cseg->p);
>             cseg->p = NULL;
>           }
>
> seems to conflict with this, since it'll try to concatenate onto a NULL
> pointer, corresponding to a packet with no data.  We get a segv here since
> we're lucky enough to be under an MMU.

Sounds like you've found a bug.  Out of order segments are pretty rare
things, which is why this won't have been spotted before.  Replacing the

pbuf_chain(pcb->recv_data, cseg->p);

with

if(pcb->recv_data)
  pbuf_chain(pcb->recv_data, cseg->p);
else
  pcb->recv_data = cseg->p;

would seem to be a suitable fix.

Hope that helps,

Kieran

[This message was sent through the lwip discussion list.]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]