Post Go back to editing

LWIP fragmentation and reassembly

Hi,

i am having problems with reassembling udp data packet fragments in the lwip stack that is supplied with the latest visualDSP (5.0 update 6).  When i try to receive upd packets (blocking calls) from my application that are smaller than the MTU of the ethernet, the receive-function of the lwip stack returns with the correct data. When i try to receive packets greater than the MTU of the net, the blocking receive-call does not return from the lwip stack, although the (fragmented) packets and all data is visible on the net.

This seems to be a bug on reassembling the ip fragments. In the changelog of the LWIP CVS there were some bugfixes to this issue some time ago. The source files of the lwip shipped with VisualDSP seem to be quite old. Will there be an update for the LWIP stack in the next time?

Has anyone expirienced similar problems and tried the compile the latests LWIP sources?

I would be greateful for some response.

adt

  • Hi,

    I have moved this thread from the Software Modules, Starter Kits and Software Development Kits category, to the VisualDSP++ Development Tools category, as the port of the LwIP stack is part of the VisualDSP++ tools.

    We are currently running version 1.3.0 of the LwIP stack (though we continue to also make bug fixes, and submit them back to Savannah to improve the stack), as of VisualDSP++ 5.0 Update 3. As you may be aware, packet fragmentation was a pretty big problem in older versions of LwIP - resulting in up to 3minutes of lost packets for a single missed packet fragment - and improvements were made as of v1.3.0.

    It is now the case that if a fragment is lost within a datagram, a timer based check is performed at 1 second intervals for up to 3 seconds. If, after 3 seconds, the fragment isn't received, the datagram is discarded. While this is an improvement over previous versions of LwIP, it is still not ideal.

    From the changelog, it appears that there have been a couple of bug fixes in 1.3.1 and 1.3.2, but it's hard to say whether these could be causing the issue you are facing, without more detail.

    It would be good to know which processor and silicon revision you are using, also. e.g. BF537 rev 0.3.

    regards,

    Craig.

  • Hi Craig,

    i am using the BF561 revision 0.5 DSP (EZ-KIT Lites 5.0.7.12).

    The point is, that the ip fragments does not seem to get lost on the LAN, because i can see them with a packet sniffer. May this be a buffer overflow on the ethernet-device? I configured the ethernet and the lwip to use several megabyte of L3-Memory  (ADI_ETHER_CMD_SUPPLY_MEM ..), so a buffer overlow should be unlikely.

  • This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

    Thank you,
    EZ Admin