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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] 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:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of *Martin Birkebæk, IO-Connect ApS > *Sent:* Monday, April 07, 2008 10:26 AM > *To:* [email protected] > *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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
