[Top][All Lists]
[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.]
- [lwip-users] Re: [lwip] TCP ack segment versus OOSEQ handling,
Kieran Mansley <=