buglwIP - A Lightweight TCP/IP stack - Bugs: bug #30625, netif/etharp assertion failure

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #30625: netif/etharp assertion failure

Submitted by:  Charles Landau <clandau>
Submitted on:  Mon 02 Aug 2010 04:32:11 AM UTC  
 
Category: ARPSeverity: 3 - Normal
Item Group: Crash ErrorStatus: Fixed
Privacy: PublicAssigned to: Simon Goldschmidt <goldsimon>
Open/Closed: ClosedPlanned Release: None
lwIP version: Other

Tue 03 Aug 2010 01:37:43 PM UTC, comment #4:

Thank you. I wonder if you could also document in pbuf.h the conditions under which the len field may or may not be zero? Then future developers will be more likely to maintain the rule.

Charles Landau <clandau>
Tue 03 Aug 2010 08:39:59 AM UTC, comment #3:

Fixed in UDP and RAW by not chaining zero-length pbufs.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 02 Aug 2010 04:38:29 PM UTC, comment #2:

I'd rather solve this by not including the zero-length pbuf since for other places throughout the stack, Len==tot_Len is a marker for packet-end, so zero length pbufs are in fact not valid.

And if udp does not copy that pouf (there's no need to - maybe we have to check raw, too), then pouf_copy will not have a problem, since it is not called with such a pbuf queue.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 02 Aug 2010 05:11:46 AM UTC, comment #1:

pbuf_copy also has trouble with that zero-length packet. Attached is a suggested fix for that.

(file #21125)

Charles Landau <clandau>
Mon 02 Aug 2010 04:32:11 AM UTC, original submission:

lwIP crashed in etharp_query with the message "no packet queues allowed!". I didn't find any reference to this in the lwip-devel mailing list or existing bugs here, but I did find this email thread on the web:
http://osdir.com/ml/network.lwip.general/2007-06/msg00151.html
which documents how the code came to be what it is:

LWIP_ASSERT("no packet queues allowed!", (p->len != p->tot_len) || (p->next == 0));

Unfortunately that is the wrong fix. It fails when I send a zero-length UDP packet to a destination that is not already in the ARP cache. A header gets chained in front of the packet in udp_sendto_if, so when it reaches the assertion in etharp_query, p points to the pbuf containing the header and p->next points to the pbuf containing the original (zero length) payload. The assertion fails.

The correct test is:

(p->next == NULL) || (p->tot_len == p->len + p->next->tot_len)

This is in lwIP version 1.3.2 (which, by the way, isn't an option under "lwIP version" when submitting a bug).

(I'm using the TIME protocol in RFC868, in which a request is any UDP packet including a zero-length packet.)

Charles Landau <clandau>

 

Attached Files
file #21125:  diffout added by clandau (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by goldsimon (Posted a comment)
  • -unavailable- added by clandau (Submitted the item)
  • -unavailable- added by clandau
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 03 Aug 2010 08:39:59 AM UTCgoldsimonStatusNone=>Fixed
      Assigned toNone=>goldsimon
      Open/ClosedOpen=>Closed
    Mon 02 Aug 2010 05:11:46 AM UTCclandauAttached File-=>Added diffout, #21125
    Mon 02 Aug 2010 04:32:11 AM UTCclandauCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1