On Mon, 2011-02-14 at 07:30 -0700, [email protected] wrote: > > We have been using lwip version 1.2
I would strongly suggest upgrading. 1.2 is years out of date and even more unsupported than the current version (we're about to release 1.4.0). > At this point, we are not using any TCP options, so we believe 1460 > would suffice. I would definitely appreciate any feedback on that > assertion. 1460 sounds good to me. > In our case the p->tot_len is 3016, and the sum of > the p->len is 1516. Since the loop is traversing the packet chain > until the tot_len is zero, this walks off the end of the chain. > > What I'm unsure of is whether the IP fragmentation code can tolerate > this misconfiguration of the MTU, or whether there is likely an error > in the fragmentation code, or perhaps in one of our drivers. I'm not sure which is to blame either, but with mismatch between p->tot_len and sum(p->len) is definitely a problem. As I said before, I'd strongly suggest upgrading to 1.4.0 as there's a chance this was an lwIP bug that was already fixed (although it doesn't sounds familiar to me). > Any thoughts on this are greatly appreciated. Additionally, since we > are executing in a real-time multi-threaded environment our > investigation is focusing on timing and race condition scenarios. Feel > free to chime in with observations and experience in those areas as > well. You have to be particularly careful with lwIP in these environments and ensure that only one thread is active in the lwIP core at once. A common way that failure to do this manifests itself is for lists of PCBs or pbufs to become corrupted. This therefore might be the cause of your problem. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
