The failure scenario is a bit more complicated... Give me some time and I will provide a correct and reproducible example, with a clear explanation.
On Mon, May 29, 2023, 13:27 Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote: > > sendfile should return an error in this case, but senfile should only be > > used with TCP, not UDP, since sendfile doesn't have any logic to ack or > > retry.. > > Sorry if this wasn't clear. This last test was with plain old `send()`... > > I opened a UDP socket, and used `send()` to transmit a buffer larger than > the MTU. > Instead of getting an error, the application hangs indefinitely. > `devif_send()` is called periodically, but of course it always fails. > > > > On Mon, May 29, 2023 at 1:13 PM Xiang Xiao <xiaoxiang781...@gmail.com> > wrote: > >> On Mon, May 29, 2023 at 5:02 PM Fotis Panagiotopoulos < >> f.j.pa...@gmail.com> >> wrote: >> >> > > 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. >> > >> > >> sendfile should return an error in this case, but senfile should only be >> used with TCP, not UDP, since sendfile doesn't have any logic to ack or >> retry.. >> >> >> > >> > >> > 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. >> > > > >> > >> > > > >> >> > > > > >> > > > >> > > >> > >> >
