While experimenting with MTU, and checking the stability of my system, I noticed the following.
I try to send a UDP datagram that is larger than the configured MTU. In this case, the offending thread seems to hang indefinitely (or at least waiting for a very long timeout?) The problem seems to be this line: https://github.com/apache/nuttx/blob/master/net/udp/udp_sendto_unbuffered.c#L197 `devif_send()` fails because the datagram is too large, but `pstate->st_sem` is never posted (the code returns immediately). This leaves the sending task to be blocked here: https://github.com/apache/nuttx/blob/master/net/udp/udp_sendto_unbuffered.c#L469 Shouldn't this failure also post the semaphore? And let the code proceed returning an error in `send()`? On Sun, May 28, 2023 at 5:26 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote: > > On Sat, May 27, 2023 at 5:35 PM Xiang Xiao <xiaoxiang781...@gmail.com> > wrote: > >> On Sat, May 27, 2023 at 8:19 PM Fotis Panagiotopoulos < >> f.j.pa...@gmail.com> >> wrote: >> >> > Hello, >> > >> > I encounter some problems using sendfile(). >> > >> > I am using sendfile to... send a file to a remote server, with my own >> > implementation of an FTP client. >> > sendfile() indeed starts to transmit chunks of the file, but as I see in >> > Wireshark, I get an ICMP response "Destination unreachable >> (Fragmentation >> > needed)". >> > I have verified that the Ethrenet MTU is correctly set to 1500. >> > >> > I tried lowering the MTU a lot (1000 bytes), and the problem is solved. >> > Communication succeeds. >> > >> > This raises some questions, and indicates some potential bugs: >> > >> > 1. Why is there a problem with MTU in the first place? Shouldn't MTU be >> > negotiated? (Is this functionality available in NuttX?) >> > >> >> MTU isn't negotiated but a physical attribute of your transport(netdev). >> On >> the other hand, PMTU could be discovered from ICMP. >> > > I am not very familiar with MTU negotiation, so it seems that it doesn't > happen in the network layer that I thought... > > >> >> >> > 2. Why is the ICMP response not handled? It seems that sendfile() just >> > ignores it and continues to send chunks, nevertheless. >> > >> >> It is handled by the recent addition here: >> https://github.com/apachey/nuttx/pull/9254 >> <https://github.com/apache/nuttx/pull/9254> >> but this feature is disabled by default, you have to enable it manually.. >> > > I will definitely take a look at this. Thank you. > > >> >> > >> > 3. Why sendfile() sends TCP segments without receiving any ACKs back? >> > AFAIK, depending on the configuration, TCP allows at most two pending >> > segments on the wire. But I see dozens of them, till sendfile finally >> > fails. >> > >> > >> Why only two segments? TCP can send packages until the slide window is >> full. >> >> Disregard this. I was confused with delayed ACKs. Which is a receiver's > functionality, not a sender's... > > >> >> > This last point is also verified in my MQTT client. >> > I have seen NuttX TCP allowing sending lots of TCP segments without >> ACKing >> > the previous data. >> > >> > So, is there any insight on the above? >> > Is my configuration wrong, or is there anything wrong with TCP? >> > >> > Thank you. >> > >> >
