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. > >> > > >> > > >
