buglwIP - A Lightweight TCP/IP stack - Bugs: bug #28519, lwip_recvfrom bug with len >...

 
 

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

bug #28519: lwip_recvfrom bug with len > 65535

Submitter:  Stephane Lesage <slesage>
Submitted:  Fri 08 Jan 2010 07:01:20 AM UTC
   
 
Category:  sockets/netconn Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  CVS Head

Jump to the original submission

Sat 09 Jan 2010 12:28:35 PM UTC, comment #6: 


> int and size_t could in theory be different.


But since the return value is int, too, I think it's enough to calculate in int instead of size_t: if the result is too big for int, it will get corrupted when returned, anyway.

> Could size_t be a poor choice for some platforms?


It might, but so far, we chose to keep the function definitions according to the standard (as available on www.opengroup.org).

Simon Goldschmidt <goldsimon>
Group administrator
Fri 08 Jan 2010 05:55:23 PM UTC, comment #5: 

Could size_t be a poor choice for some platforms?  Or possibly a type that effects the stack negatively?  Your own lwip_size_t would allow it to be different from size_t if that ever were to make sense.

Bill Auerbach <billauerbach>
Fri 08 Jan 2010 04:21:28 PM UTC, comment #4: 

int and size_t could in theory be different.

Kieran Mansley <kieranm>
Group Member
Fri 08 Jan 2010 04:01:53 PM UTC, comment #3: 


> Should you consider using lwip_size_t which defaults to size_t?
> Could there be an implementation where size_t isn't optimal?


Doesn't using 'int' solve this?

Simon Goldschmidt <goldsimon>
Group administrator
Fri 08 Jan 2010 02:59:53 PM UTC, comment #2: 

Should you consider using lwip_size_t which defaults to size_t? Could there be an implementation where size_t isn't optimal?

Bill Auerbach <billauerbach>
Fri 08 Jan 2010 02:51:36 PM UTC, comment #1: 

Fixed using 'int' for 'off' (because return value is 'int', too). Thanks for reporting!

Simon Goldschmidt <goldsimon>
Group administrator
Fri 08 Jan 2010 07:01:20 AM UTC, original submission:  

Hi,
 
I had a non-reproductible problem with my http server while reading of big POST.
Sometimes read() would return 0 = connection closed for no reason.
On a simplified version of a firmware I've recently made, it was systematic.
 
So I enabled LWIP debugging, but I had no warning/severe error.
Then I enabled all SOCKETS_DEBUG messages, and I got the attached output.
 
The reason I get 0 from read() is actually very simple.
I call read() with a very big malloc()ed buffer because I know the content length from the POST headers.
 
read() parameter len is size_t, but the variable off in lwip_recvfrom() is only u16_t.
Guess what happens when we accumulate data in the buffer and update the variable off...
 
modifications to lwip_recvfrom() in sockets.c:
- declare off as size_t
- change format specifiers to SZT_F for debug output
 
Now it works correctly.

Stephane Lesage <slesage>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #19437:  lwipdebugout.txt added by slesage (20KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by billauerbach (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by slesage (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-01-08 goldsimon StatusNone Fixed
        Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2010-01-08 slesage Attached File- Added lwipdebugout.txt, #19437

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code