lwIP - A Lightweight TCP/IP stack - Bugs: bug #47334, 6LoWPAN crashes on reassembly of...
You are not allowed to post comments on this tracker with your current authentication level.
bug #47334: 6LoWPAN crashes on reassembly of high payload lengths
Submitter: | Martine Lenders <authmillenon> | ||
Submitted: | Fri 04 Mar 2016 03:53:53 AM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | Crash Error | Status: | Works For Me |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | git head |
Jump to the original submission
Mon 07 Mar 2016 04:19:55 PM UTC, comment #19: |
Ivan Delamer <idelamer> |
Sat 05 Mar 2016 03:21:06 PM UTC, comment #18:
|
Martine Lenders <authmillenon> |
Sat 05 Mar 2016 02:34:20 PM UTC, comment #17: OK now I see: you're probably coming from a uIP world where you don't want to allocate 10 KByte for the IP stack? In lwIP, this is rather little memory, given that you allocate all memory from the heap, even all RX pbufs!
|
Simon Goldschmidt <goldsimon> |
Sat 05 Mar 2016 02:06:07 PM UTC, comment #16: (I have MEMP_MEM_MALLOC set to 1 btw) |
Martine Lenders <authmillenon> |
Sat 05 Mar 2016 01:41:09 PM UTC, comment #15:
|
Martine Lenders <authmillenon> |
Sat 05 Mar 2016 01:20:42 PM UTC, comment #14: What I don't understand is what does MEM_SIZE have to do with it? RX pbufs should be allocated as PBUF_POOL, which has nothing to do with MEM_SIZE. Could it be that you allocate RX pbufs as PBUF_RAM and allocate them much bigger than the 127 bytes required for 6lowpan? |
Simon Goldschmidt <goldsimon> |
Sat 05 Mar 2016 01:06:41 PM UTC, comment #13:
|
Martine Lenders <authmillenon> |
Sat 05 Mar 2016 12:26:50 PM UTC, comment #12:
|
Simon Goldschmidt <goldsimon> |
Fri 04 Mar 2016 10:06:40 PM UTC, comment #11:
|
Martine Lenders <authmillenon> |
Fri 04 Mar 2016 08:32:56 PM UTC, comment #10:
|
Simon Goldschmidt <goldsimon> |
Fri 04 Mar 2016 06:22:43 PM UTC, comment #9:
|
Simon Goldschmidt <goldsimon> |
Fri 04 Mar 2016 05:32:31 PM UTC, comment #8: Ah you were refering to the MTU of IPv6 over IEEE 802.15.4. This is of course correct (and I'm not going over it btw). I thought you were refering to the general MTU in the scope IPv6. |
Martine Lenders <authmillenon> |
Fri 04 Mar 2016 05:26:55 PM UTC, comment #7: The MTU for transmission of IPv6 packets over IEEE 802.15.4 is set to 1280.
|
Ivan Delamer <idelamer> |
Fri 04 Mar 2016 05:21:23 PM UTC, comment #6: This is not correct. 1280 is the minimum MTU (source: https://tools.ietf.org/html/rfc2460#section-5). Otherwise the M in MTU would be quite redundant and the fragmentation and compression in 6LoWPAN would not been required ;-).
|
Martine Lenders <authmillenon> |
Fri 04 Mar 2016 05:09:39 PM UTC, comment #5: Please note that max MTU is 1280, although it should be safe if we receive larger packets.
|
Ivan Delamer <idelamer> |
Fri 04 Mar 2016 02:04:24 PM UTC, comment #4: (so we are talking about the range of 12-14 received fragments here) |
Martine Lenders <authmillenon> |
Fri 04 Mar 2016 01:58:49 PM UTC, comment #3: This issue was written very badly.... It was very late and I was about to go to bed. Sorry for that. I also forgot to mention that this only happens for very big (but within the range of IPv6's minimum MTU of 1280 byte) IPv6 datagrams. |
Martine Lenders <authmillenon> |
Fri 04 Mar 2016 01:49:50 PM UTC, comment #2: Sorry, I meant `MEM_USE_POOLS` (^.^).
|
Martine Lenders <authmillenon> |
Fri 04 Mar 2016 07:31:45 AM UTC, comment #1: What does LWIP_USE_POOLS mean? I can't find that in the sources.
|
Simon Goldschmidt <goldsimon> |
Fri 04 Mar 2016 03:53:53 AM UTC, original submission:
For an evaluation of several stacks I flood the stacks (admittedly with a virtual network device so next to no delay compared to realistic situations). After the introduction of 6LoWPAN to your stack last week I also considered it, but currently I need to set the `MEM_SIZE` value (with `LWIP_USE_POOLS`) to a comparably very big value (10592 + stack size for TCP/IP thread for a Cortex-M platform [this one: https://www.iot-lab.info/hardware/m3/, but I also saw the same behavior this one]). Otherwise, the stack can't reassemble the packet since it runs out of memory or some cases even crashes. |
Martine Lenders <authmillenon> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2016-03-05 | goldsimon | Assigned to | None | goldsimon | |
Open/Closed | Open | Closed | |||
2016-03-04 | goldsimon | Status | None | Works For Me |
Powered by Savane 3.13-02a9.
Corresponding source code
I'm going to suggest that this is probably due to the other open bug, where the packet field is probably not calculated properly. So it might be that complete packets are remaining in queue because of a miscalculation of expected size. Lets test this again after we fix the open bug (sometime this week I hope)