[Bug] MavlinkReceiver over UDP deadlocks on NuttX under high traffic

Describe the bug

I am running into an issue where the MAVLink communication over UDP drops-out and the only way to recover is to restart PX4.

In MavlinkReceiver::run the UDP socket is sequentially calling recvfrom()'ed (after a poll) and sendto()'d. The UDP readahead queue exhausts the available memory from the IOB pool, leaving nothing left for transmission. The UDP socket is created as blocking with an infinite timeout, which causes the task to hang indefinitely on any sentdo() if this memory is exhausted, as the readahead queue is only freed in recvfrom().

NuttX has the CONFIG_IOB_THROTTLE option specifically created to prevent this kind of issue, but it is currently bugged both in upstream and PX4's fork.

The other option that should help is setting CONFIG_NET_RECV_BUFSIZE to directly limit the amount of memory the readahead queue may use but that is also bugged. It compares against the size of the bytes in-use, instead of the size of the buffer itself: iob_get_queue_size sums io_pktlen, not the size of the buffers. Testing this option did indeed lead to such a situation: the reported bufsize was ok even though all IOB buffers were allocated to the readahead queue and far exceeded NET_RECV_BUFSIZE.

In conclusion, I don't see an easy config option to alleviate this problem.

I am unsure what direction I should go to try and get this solved.

1. Getting the fix into NuttX and backporting would be a lot of effort due to the IOB system having changed quite a bit.
2. Fixing RECV_BUFSIZE (and SEND_BUFSIZE) to check the against the size of the whole buffer.
3. Rewrite MavlinkReceiver::run to use a non-blocking socket or with a timeout.

I have tested both option 2. and 3. and verified that they work.

To Reproduce

1. Compile PX4 with NuttX with CONFIG_MM_IOB=y and small values for _IOB_NBUFFERS, _IOB_BUFSIZE _IOB_NCHAINS such as 128, 128, 128. Large values experience the same issue but are much harder to trigger.
2. Use QGroundControl to download a log file over UDP
3. Transfer speeds drop to 0
4. Drone becomes unresponsive

Expected behavior

The log file transfers without issues. Afterwards communication is still ongoing.

Screenshot / Media

No response

Flight Log

No response

Software Version

Fork of PX4 version: 25.6.19 0 (419828480)

Flight controller

No response

Vehicle type

None

How are the different components wired up (including port information)

No response

Additional context

No response