How to receive a 4k UDP packet when my MTU is 1500, using fragmented IP packets?

[Mz.1]

Hey,

I Have STM32H743Zi

I'm new at this, so please forgive me if I'm unclear.

I'm trying to receive 4k UDP packets but I'm getting only 1k each time.

I did a Google search and understand that if I want to receive a UDP packet of 4k I need to use fragmentation due to the MTU being 1500.

I tried to enable the below parameters:

IP_REASSEMBLY - enabled

MEMP_NUM_REASSDATA - 5

IP_REASS_MAX_PBUFS - 10

MEMP_NUM_FRAG_PBUF - 4

inside my callback function, I'm trying to read all the 4k data, I'm getting 1k in the first node but the next node in the pbuf is always NULL.

I also see on Wirshak messages with 1k

while I'm sending using Hrecules 4k for sure.

this is the callback function code:

void UDP_TX_RECEIVE_CALLBACK(void *arg, struct udp_pcb *upcb, struct pbuf *p, const ip_addr_t *addr, u16_t port)

{

 char TxUdpPacket[SPI_PACKET_SIZE] = {0, };

 // Process each received fragment

 while (p != NULL)

 {

  // Copy fragment data to appropriate position in udpPacket array

  memcpy(&TxUdpPacket[p->tot_len - p->len], p->payload, p->len);

  // Move to the next fragment

  struct pbuf *next = p->next;

  pbuf_free(p);

  p = next;

 }

}

pls, help!!

thank you 🙂

[LCE]

> sorry I meant "function", my English is not so fluent

Oops, sorry, no offense meant!

I actually thought that "method" is some C# or Python lingo... 😅

[Piranha]

> what's a method?

Actually it's a generic term in OOP:

https://en.wikipedia.org/wiki/Method_(computer_programming)

As Pavel and LCE said, jumbo frames must be enabled in hardware, because by default that feature is disabled. Once you go over the standard MTU of 1500 bytes, you risk that some devices and computers will not support it. If the environment is fully controlled, then one can deal with it reasonably. If you intend going over the internet, then it's hopeless.

But there is another catch. The ETH hardware FIFO size is 2 KB for Tx and 2 KB for Rx. If you go over this size, you open another can of worms, because Store-and-Forward mode becomes impossible. First, you loose TCP, UDP and ICMP transmit checksum offload. Second, a DMA overflow/underflow becomes a reality and must be handled in code. Third, the driver code becomes more complex and I don't know whether the HAL ETH driver supports that mode at all.

I hope you do understand that ST's broken bloatware anyway has no chance of working reliably:

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32