04-07-2010 03:27 AM
I have an embedded system implemented in a ML507 board. The system hardware is equal to that in xapp1026, it includes a XPS_LL_TEMAC IP core. The software in the board only has to receive UDP packets (using lwip UDP functions) and write them in a file in the DDR2(I have implemented an MFS file system). The thansmitter of the UDP packets can send then with a configurable length. When the length is bigger than 1500 bytes the transmitter fragments then in IP packets with a maximum length of 1500 bytes. So the ML507 boards receives the UDP packets already fragmented when the size is bigger than 1500 bytes.
If I configure the TX for sending packets less than 1500 bytes the ML507 works properly, receives the packets and save them in the file. But when the UDP packets are fragmented the project does not work. It seems that all the fragments are received by the board and it detects that are fragments and also it recognise that the last fragment has arrived, but it is not able to reassemble them. At last the function defined in udp_recv() is never called.
Has somebody had the same problem?, how must I configure the lwip, the pbufs, the TEMAC, and so on, to be able to receive fragmented UDP packets?. I need to enable Jumbo frames?.
08-12-2010 03:11 PM
I am currently having the same problem (noticing the same behavior, anyway).
With ip_debug on, I can see the packets received correctly at that layer, and ip_reass called to defragment. However, the udp recv callback is never entered. Of course, this is for packets larger than the Ethernet frame size (non-jumbo frames).
You posted some months ago; have you figured it out?
08-13-2010 12:31 PM
I tried tracing execution through the ip_reass, and when the last fragment in the datagram arrives, it is successfully identified as such (MS = 0?), but fails the vaildation (and hence the datagram is never fully reconstructed).
As a work around, I configure the PC driver to limit the datagram size to the Ethernet MSS, so fragmentation never actually occurs. I have very controlled use over my system configuration, so this is probably ok for now.