RE: [lwip-users] lwip 1.3.0 "ping of death"

[John Keil]

I just checked IP_FRAG_USES_STATIC_BUF=0, and that also corrects the problem
for us.

We use 128-byte alignment to keep the buffers cache-aligned to make DMA
transfers in our driver more efficient (we use lwIP with our products that
are based on TI 6711 and 645x DSPs).  A little unusual probably, but in this
case it made finding the problem easier since it wiped out a big chunk of
data instead of just a couple bytes!

John

-----Original Message-----
From: address@hidden
[mailto:address@hidden
Behalf Of address@hidden
Sent: Thursday, April 10, 2008 1:20 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] lwip 1.3.0 "ping of death"


Thanks for that, I think that's really helpful! I don't think any of the
developers has tested the stack with a MEM_ALIGNMENT of as much as 128
lately...

Just one more question: am I right in assuming you didn't have any
problems with IP_FRAG_USES_STATIC_BUF =0, or did you just not try that?

Simon


John Keil wrote:
> We were also experiencing the "ping of death" with lwIP 1.3.0, and
> traced the problem to the static buffer used for IP fragmenting.
> If you are using fragmenting, and set IP_FRAG_USES_STATIC_BUF in your
> lwipopts.h file, a static buffer of size IP_FRAG_MAX_MTU is created.
> The problem is that the code to create the static buffer in ip_frag.c is:
> static u8_t buf[LWIP_MEM_ALIGN_SIZE(IP_FRAG_MAX_MTU)]; // line 602 of
> ip_frag.c
> This code rounds your IP_FRAG_MAX_MTU up to the next MEM_ALIGNMENT
> boundary. We used an MTU of 1500, with a 128-byte memory alignment, so
> the buffer became 1536 bytes. The problem is that this buffer is then
> aligned in memory to a MEM_ALIGNMENT boundary using the code:
> rambuf->payload = LWIP_MEM_ALIGN((void *)buf); // line 653 of ip_frag.c
> For us, this could move the start of the buffer forward by as many as
> 124 bytes. This meant that our 1536-byte buffer sometimes had less
> than 1500 bytes actually available. When this shortened buffer was
> used, lwIP wrote into the next thing in memory (the ARP table for us),
> and made the application crash.
> You can fix this in lwipopts.h by increasing IP_FRAG_MAX_MTU by
> MEM_ALIGNMENT bytes.
> I think really the code should be fixed so line 602 reads:
> static u8_t buf[LWIP_MEM_ALIGN_SIZE(IP_FRAG_MAX_MTU+MEM_ALIGNMENT)];
> This is similar to what is done for ram_heap in mem.c, and probably
> other places in lwIP.
> Not sure if this will help for everyone, but it fixed the problem for us.
> John Keil
>
>     -----Original Message-----
>     *From:* address@hidden
>     [mailto:address@hidden
>     Behalf Of *Martin Birkebæk, IO-Connect ApS
>     *Sent:* Monday, April 07, 2008 10:26 AM
>     *To:* address@hidden
>     *Subject:* [lwip-users] lwip 1.3.0 "ping of death"
>
>     Hi list,
>
>     I have succesfully ported lwip 1.3.0 to LPC2468. Lwip is running
>     in a threaded environment, FreeRTOS. I have a basic example
>     running, with a webserver.
>
>     I have enabled ip reassembly, see my lwipopts.h file attached to
>     this mail.
>
>     I have a webbrowser running, which is requesting a webpage from
>     the webserver each second, and I am pinging the system
>     continually, through the command
>
>     Ping <ip> -t
>
>     The system is running ok. But if I ping the system with a lot of
>     data bytes, i.e. ping <ip> -l 2048. The system crashes.
>
>     I end up in an data abort exception. The reason for this
>     exception, is a pointer, r, in function ip_reass() is containing
>     an invalid address.
>
>     The line in C code is:
>
>     iprh = (struct ip_reass_helper*)r->payload; // line number: 572 in
>     ip_frag.c
>
>     What can I do, to avoid this “ping of death” ?
>
>     P.S.: Please be aware that I have yet to optimize the system
>     regarding values in lwipopts.h. But that will be a topic for
>     another question on this list.
>
>     Regards,
>
>     Martin
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users