#include "mbed.h"
#include "EthernetInterface.h"

DigitalOut led_main(LED2);

int main()
{
    char buffer[ 4096 ];
    
    // Add some data to the buffer
    for ( unsigned i = 0; i < sizeof(buffer); ++i )
    {  buffer[ i ] = i; }

    // Ethernet Interface
    EthernetInterface eth;
    eth.init( "192.168.1.208", "255.255.255.0", "" );
    eth.connect();

    // Set up Socket and Endpoint
    UDPSocket socket;
    socket.init();
    socket.set_broadcasting();
    socket.set_blocking( false, 5000 );
    Endpoint endpoint;
    endpoint.set_address( "192.168.1.255", 30000 );
    
    
    bool on = false;
    while ( true ) {
        led_main = on;
        socket.sendTo(endpoint, buffer, sizeof(buffer) );
        on = !on;
        wait( 5.0 );
    }
}

Hi, I'm trying to send some simple UDP Packets from the mbed to the network. When the packets are small, everything is working fine and I can achieve rather high bandwith. The problem comes when packet size gets too big, there seems to be a problem in the ip packet fragmentation. Example code: <<code title="Ethernet Test">> #include "mbed.h" #include "EthernetInterface.h" DigitalOut led_main(LED2); int main() { char buffer[ 4096 ]; // Add some data to the buffer for ( unsigned i = 0; i < sizeof(buffer); ++i ) { buffer[ i ] = i; } // Ethernet Interface EthernetInterface eth; eth.init( "192.168.1.208", "255.255.255.0", "" ); eth.connect(); // Set up Socket and Endpoint UDPSocket socket; socket.init(); socket.set_broadcasting(); socket.set_blocking( false, 5000 ); Endpoint endpoint; endpoint.set_address( "192.168.1.255", 30000 ); bool on = false; while ( true ) { led_main = on; socket.sendTo(endpoint, buffer, sizeof(buffer) ); on = !on; wait( 5.0 ); } } <</code>> Even with the massive 5s delay, the receiver ( desktop pc, linux or windows, using wireshark to analyze traffic ) misses a lot of the supposedly fragmented packets. <<quote>> No. Time Source Destination Protocol Length Info 584 1.838882000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05da) 1549 6.839170000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05dd) 3125 11.839513000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05de) 4713 16.839856000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05e2) 6306 21.840125000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05e5) 7905 26.840468000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05e8) 9494 31.840729000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05ec) 11141 36.841056000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05f2) 12730 41.841364000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05f6) 14322 46.841556000 192.168.1.208 192.168.1.255 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=05fb) 14323 46.841826000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05fb) 15926 51.842015000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=05ff) 17511 56.842300000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=0603) 19098 61.842606000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=0607) 20685 66.842914000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=060d) 22256 71.843228000 192.168.1.208 192.168.1.255 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=0611) [Reassembled in #22258] 22257 71.843455000 192.168.1.208 192.168.1.255 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=1480, ID=0611) [Reassembled in #22258] 22258 71.843458000 192.168.1.208 192.168.1.255 UDP 1178 Source port: 49153 Destination port: 30000 23849 76.843630000 192.168.1.208 192.168.1.255 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=0616) 23850 76.843856000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=0616) 24885 81.844061000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=061a) 26480 86.844388000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=061b) 28086 91.844699000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=061f) 29671 96.844994000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=0623) 31268 101.845252000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=0628) 32852 106.845605000 192.168.1.208 192.168.1.255 IPv4 1178 Fragmented IP protocol (proto=UDP 17, off=2960, ID=062c) <</quote>> Is there any known bug or restriction causing this? Originally I'm interested in trying to send 16384 Byte packets, but if that isn't possible I need to stay with small packets size and either adding my own protocoll for packet offset, or delegate synchronization of the data stream to the receiver.

Which platform are you using?

I'm using the EA LPC 4088 Quick Start Board. I remember having the same problem with the mbed LPC 1768 as well 4-5 months ago, but back then I just avoided it by switching to smaller packets. If necessary I could re-test with it as well. I also just did a quick test with a 1024 Byte buffer on the lpc 4088, without the 5.0s wait, and getting nearly 50MBit/s without problems.