> You need to enable IP fragmentation in this case, which is also added > recently and disabled by default: > https://github.com/apache/nuttx/pull/8059 <https://github.com/apache/nuttx/pull/8059> > Otherwise, any packet bigger than MTU will be dropped silently.
Yes, this is the expected behavior. But, instead of dropping the packet, the system hangs because the semaphore is never posted. It just tries endlessly to call devif_send() which always fails. On Mon, May 29, 2023 at 11:42 AM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > On Sun, May 28, 2023 at 11:55 PM Fotis Panagiotopoulos < > f.j.pa...@gmail.com> > wrote: > > > 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?) > > > > You need to enable IP fragmentation in this case, which is also added > recently and disabled by default: > https://github.com/apache/nuttx/pull/8059 > Otherwise, any packet bigger than MTU will be dropped silently. > > > > 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. > > >> > > > >> > > > > > >
