Re: sendfile() problems - Destination unreachable

[Xiang Xiao]

On Sun, May 28, 2023 at 11:55 PM Fotis Panagiotopoulos 
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  >
> wrote:
>
> >
> > On Sat, May 27, 2023 at 5:35 PM Xiang Xiao 
> > 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
> >> 
> >> 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.
> >> >
> >>
> >
>

Re: sendfile() problems - Destination unreachable

[Fotis Panagiotopoulos]

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

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

Re: CI tests (was: Re: [OT] Learning Makefiles)

[Michael Gielda]

Haha, no worries, just subscribed on Friday for this particular reason :)
glad Renode was useful for EOS S3 and of course happy to see how we can
enable more of that.


You mention you have a CI generating all the elfs, could you point me to
where that can be found? We could grab those and try to run them, see what
happens.


I can explain how we approach the platform generation we are doing for
Zephyr/U-Boot now to see how we could make it work for NuttX. Basically we
have this https://github.com/antmicro/dts2repl utility which uses the
Zephyr device trees generated with its build systems - with some
hand-written overlays (
https://github.com/antmicro/dts2repl/tree/main/dts2repl/overlay) which we
try to minimize / incorporate into the Zephyr device trees - into Renode's
repl files (platform files, the ones describing HW platforms). For the
simulation scenario, or .resc files, we have a template that's standard
across all platforms for a specific Zephyr demo. Same could be done for
NuttX of course.


Then we use this to run all the tests across all the platforms, and gather
and visualize the results.


If, when running NuttX (or any other payload) on those platforms we find
some of our platforms descriptions lacking some specific stuff like power
or clock management, we would add the necessary stuff into the overlays (or
Zephyr’s dts if possible)


I think some STM32 platforms would be a good entry point, since there are
many and they are pretty well supported in Renode/Zephyr/NuttX. But again,
if you point me to the elf files you are hosting, we could probably consume
them and report the results.


CCing my team to follow the conversation. They will have more details if
needed.


Best regards,

Michael


On Sat, 27 May 2023 at 01:01, Brennan Ashton 
wrote:

> Still dropped him. Apparently I cannot use email correctly today...
>
> On Fri, May 26, 2023, 3:40 PM Brennan Ashton 
> wrote:
>
>> Adding Michael back since I responded to him and he might not be on the
>> list...
>>
>> On Fri, May 26, 2023 at 3:23 PM Brennan Ashton
>>  wrote:
>> >
>> >
>> >
>> > On Fri, May 26, 2023, 3:11 PM Michael Gielda 
>> wrote:
>> >>
>> >> Hi Alan, nice to meet you Nathan,
>> >>
>> >> Indeed, we discussed with Alan some time ago, having a Nuttx-focused
>> >> dashboard can be done and we assume would be useful. We just didn’t
>> get to
>> >> that as it would have been yet another research project (we are now
>> also
>> >> building a U-Boot dashboard, as we added 64-bit Cortex-A support -
>> >> https://antmicro.com/blog/2023/04/armv8-a-support-in-renode/ - as
>> well as
>> >> Cortex-R). But if there is interest, perhaps it’s worth revisiting the
>> idea.
>> >>
>> >> On our end, we base the simulation platform configuration on Zephyr,
>> so we
>> >> basically need a mapping of platforms in Nuttx to their “Zephyr names”
>> - we
>> >> can start of course with 1-2 and expand to more with time.
>> >>
>> >> Best regards,
>> >>
>> >> Michael
>> >
>> >
>> > Hey Michael,
>> > I actually had used renode when added upstream support a few years ago
>> with the QuickLogic EOS S3, and it was quite helpful.  That's when I talked
>> a bit about seeing if we could use it as a test platform here.
>> https://docs.google.com/presentation/d/1G1IKe3SjmB42eb7dhdoa4P_nREknsJy1/edit#slide=id.g9044e8e6ab_0_17
>> >
>> > One of the reasons I added support to export build artifacts in CI was
>> to enable having downstream stages that can pick up the already generated
>> elf.
>> >
>> > One thing at the time I hit with the targets I tested was some
>> assumptions around power and clock management that prevented NuttX from
>> booting (waiting for status bits usually).  So if we do go down this route
>> I suspect we will need to upstream some of those bits to the emulation
>> which I don't recall being too complicated.
>> >
>> > If people have a supported platform they would like to see I would be
>> happy to wire a proof of concept through.
>> >
>> > --Brennan
>>
>

-- 
Michael Gielda
mobile: +46 73 759 47 27
Antmicro AB | www.antmicro.com
Kistagången 16, 164 40 Kista, Sweden

Re: sendfile() problems - Destination unreachable

[Xiang Xiao]

On Mon, May 29, 2023 at 5:02 PM Fotis Panagiotopoulos 
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
> 
> > 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 
> 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
> > > >> 
> > > >> 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 anythi

Re: sendfile() problems - Destination unreachable

[Fotis Panagiotopoulos]

> 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 
wrote:

> On Mon, May 29, 2023 at 5:02 PM Fotis Panagiotopoulos  >
> 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
> > 
> > > 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 
> > 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
> > > > >> 
> > > > >> 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 

Re: sendfile() problems - Destination unreachable

[Fotis Panagiotopoulos]

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

Re: sendfile() problems - Destination unreachable

[Fotis Panagiotopoulos]

I can see that there are two different problems with MTU.
They are completely independent from each other, so let's start with the
simple case first.

I am testing on an STM32F427, using Ethernet.

As previously noted, the following code will cause the running task to hang.

netlib_set_mtu(CONFIG_NETIF_DEV_NAME, 1500);

int sd = socket(AF_INET, SOCK_DGRAM, 0);

struct sockaddr_in server;
server.sin_family  = AF_INET;
server.sin_port= 1000;
server.sin_addr.s_addr = inet_addr("192.168.1.235");

uint8_t * data = malloc(2048);
memset(data, 0xAA, 2048);

sendto(sd, data, 2048, 0, (struct sockaddr*)&server, sizeof(server));

close(sd);

As you can see, the MTU is set to 1500, and then I try to send a UDP
datagram with a larger size (2048).
Indeed `devif_send()` fails, and the aforementioned semaphore is never
posted.

(This is without buffering in UTP, in case this is important).

This draft PR, provides a solution to the issue.
https://github.com/apache/nuttx/pull/9423

If this is correct, I will also check buffered UDP, and other uses of
devif_send().

Alternatively, devif_send() may be changed to actually return an error code
(instead of returning void), so improved error handling can take place.


On Mon, May 29, 2023 at 1:41 PM Fotis Panagiotopoulos 
wrote:

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