You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Adam Feuer <ad...@starcat.io> on 2020/01/11 02:56:33 UTC
Re: thttpd question (TCP close problem?)
After debugging, it seems like the TCP connection is not being closed
correctly, and the client receive times out.
Could this be the TCP close problem that has been reported? When was it
introduced? I'd like to go back to a previous version and see if that works
correctly.
-adam
On Fri, Jan 10, 2020 at 16:32 Adam Feuer <ad...@starcat.io> wrote:
> Hi,
>
> I got the uIP webserver example to work on the SAMA5D36-Xplained. However,
> it's not fast enough for my needs. (Probably to be expected since it's
> designed for low-power devices.)
>
> I am trying to get the thttpd example to work. It compiles, and I can run
> the thttp command from the NuttX shell. It will serve about 75% of the
> index page, and then appears to hang– the page never finishes transmission.
> I'm going to debug, but I thought I'd ask:
>
> Has anyone seen this before? If so, what's wrong and how do I fix it?
>
> cheers
> adam
> --
> Adam Feuer <ad...@starcat.io>
>
--
Adam Feuer <ad...@starcat.io>
Re: thttpd question (TCP close problem?)
Posted by Adam Feuer <ad...@starcat.io>.
Greg,
Thanks, I will try to use the host client programs. I just need to see if I
can get them compiled on Linux.
Re: link speed, 100 Mbps using Ethernet over USB would work. Higher would
be better. The network I want this to work on is just from the NuttX box to
the host computer. The host is directly plugged into the NuttX via a USB
cable.
For my Gigibit Ethernet tests, I'm using a USB 3.0 USB to Ethernet adapter
directly plugged in to the SAMA5D36 GMAC ethernet port. So I should not
expect the USB link to be the bottleneck. It should have 5 Gbps total
bandwidth.
-adam
On Sun, Jan 12, 2020 at 1:52 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> > Thanks, that document is very helpful. I set up TCP Blaster as a client,
> > not a server, just because it was easier for me to send data from Linux
> > with netcat. I'll try it as a server, I just have to look up the right
> > netcat params.
>
> I am not sure if you should not use netcat. When you build
> apps/examples/tcpblaster it will build the matching host side of the
> test. Best to use the version generated by
> build/apps/examples/tcpblaster. It will leave the host program in the
> apps/examples/tcpblaster directory. The host program will be called
> either tcpclient or tcpserver, depending upon how you have the example
> configured.
>
> > I am glad to hear from you that's your experience was that NuttX is
> limited
> > by the network. That's great! :) I do think high speed transfers should
> be
> > possible using Ethernet over USB and I would love to get it working at
> > close to the link speed of 480Mbps. That would really help for the
> > application I'm building.
>
> The is only on Tx. The Rx side is more complex and will depending more
> on you application configuration.
>
> 480Mbps is NOT the link speed. That is the USB speed. The link speed
> will be negotiated on the network and only 10Mbit/sec or 100Mib/sec are
> likely. Are you expecting this to work on a giga-bit network? I
> suppose that will depend on the what you have plugged into the USB
> port. I have never experiment with a giga-bit network accessed via
> USB. If that is the case, then USB will be the bottle neck.
>
> More people use RNDIS and CDC/ECM. Has anyone using either USB
> networks with a giga-bit network? How did it perform.
>
> I know that Masayuki Ishikwawa has used RNDIS a lot. Perhaps he can
> respond.
>
> You might also ask on the old Google forum too. There are still 300 or
> so people still using only the Google forum (or are inactive).
>
> Greg
>
>
>
--
Adam Feuer <ad...@starcat.io>
Re: thttpd question (TCP close problem?)
Posted by Gregory Nutt <sp...@gmail.com>.
> Thanks, that document is very helpful. I set up TCP Blaster as a client,
> not a server, just because it was easier for me to send data from Linux
> with netcat. I'll try it as a server, I just have to look up the right
> netcat params.
I am not sure if you should not use netcat. When you build
apps/examples/tcpblaster it will build the matching host side of the
test. Best to use the version generated by
build/apps/examples/tcpblaster. It will leave the host program in the
apps/examples/tcpblaster directory. The host program will be called
either tcpclient or tcpserver, depending upon how you have the example
configured.
> I am glad to hear from you that's your experience was that NuttX is limited
> by the network. That's great! :) I do think high speed transfers should be
> possible using Ethernet over USB and I would love to get it working at
> close to the link speed of 480Mbps. That would really help for the
> application I'm building.
The is only on Tx. The Rx side is more complex and will depending more
on you application configuration.
480Mbps is NOT the link speed. That is the USB speed. The link speed
will be negotiated on the network and only 10Mbit/sec or 100Mib/sec are
likely. Are you expecting this to work on a giga-bit network? I
suppose that will depend on the what you have plugged into the USB
port. I have never experiment with a giga-bit network accessed via
USB. If that is the case, then USB will be the bottle neck.
More people use RNDIS and CDC/ECM. Has anyone using either USB
networks with a giga-bit network? How did it perform.
I know that Masayuki Ishikwawa has used RNDIS a lot. Perhaps he can
respond.
You might also ask on the old Google forum too. There are still 300 or
so people still using only the Google forum (or are inactive).
Greg
Re: thttpd question (TCP close problem?)
Posted by Adam Feuer <ad...@starcat.io>.
Thanks, that document is very helpful. I set up TCP Blaster as a client,
not a server, just because it was easier for me to send data from Linux
with netcat. I'll try it as a server, I just have to look up the right
netcat params.
I am glad to hear from you that's your experience was that NuttX is limited
by the network. That's great! :) I do think high speed transfers should be
possible using Ethernet over USB and I would love to get it working at
close to the link speed of 480Mbps. That would really help for the
application I'm building.
Right now I'm trying to get the ethernet to work on the SAMA5D36-Xplained
board. NuttX compiles, but the ethernet interfaces won't go up. I am using
ETH0 with the GMAC and ETH1 with EMACA. I've set the PHYs as laid out in
the README.txt. Not sure how to debug, but I am looking for how ifconfig
tries to get the interface to come up...
On Sun, Jan 12, 2020 at 11:28 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> > Ok, thanks. I did do that yesterday with tcpdump while trying to find the
> > closing-early problem with the header lengths. Now with the header length
> > calculation things look good– at low speeds, the packet exchange matches
> > what I am getting from a Linux web server. No retransmissions, resets, or
> > missed ACKs. I will try a high-speed capture and examine it.
> >
> > I did try tcpblaster last night, and can only get about 100 KB/s maximum
> –
> > about 800kbps, so much less than the 480Mbps that's possible. So that is
> > probably part of the constraint. The SAMA5D36 has USB DMA.so it should be
> > possible to get 100Mbps or higher... I will try with the Gigabit Ethernet
> > and see if I can find the bottleneck.
>
> This might be useful to you:
> https://cwiki.apache.org/confluence/display/NUTTX/TCP+Network+Performance
>
> TCP blaster can be set up for sending to or receiving from the device.
> Which are you doing?
>
> I have verified NuttX TCP Tx performance with tcpblaster and found that
> it runs at about the maximum for the network I was using (I was using a
> slow, half duplex network). You are probably not being limited by the
> USB transfer rate, but by the network transfer rate. Well both should
> have and effect, but the (probably) network transfer rate at 100Mbit/sec
> is a lot lower than the USB transfer rate.
>
> 100KB/s is 800Kbit/sec which is considerably lower than the network
> transfer rate.
>
> Rx performance is more difficult to characterize.
>
>
>
>
>
--
Adam Feuer <ad...@starcat.io>
Re: thttpd question (TCP close problem?)
Posted by Gregory Nutt <sp...@gmail.com>.
> Ok, thanks. I did do that yesterday with tcpdump while trying to find the
> closing-early problem with the header lengths. Now with the header length
> calculation things look good– at low speeds, the packet exchange matches
> what I am getting from a Linux web server. No retransmissions, resets, or
> missed ACKs. I will try a high-speed capture and examine it.
>
> I did try tcpblaster last night, and can only get about 100 KB/s maximum –
> about 800kbps, so much less than the 480Mbps that's possible. So that is
> probably part of the constraint. The SAMA5D36 has USB DMA.so it should be
> possible to get 100Mbps or higher... I will try with the Gigabit Ethernet
> and see if I can find the bottleneck.
This might be useful to you:
https://cwiki.apache.org/confluence/display/NUTTX/TCP+Network+Performance
TCP blaster can be set up for sending to or receiving from the device.
Which are you doing?
I have verified NuttX TCP Tx performance with tcpblaster and found that
it runs at about the maximum for the network I was using (I was using a
slow, half duplex network). You are probably not being limited by the
USB transfer rate, but by the network transfer rate. Well both should
have and effect, but the (probably) network transfer rate at 100Mbit/sec
is a lot lower than the USB transfer rate.
100KB/s is 800Kbit/sec which is considerably lower than the network
transfer rate.
Rx performance is more difficult to characterize.
Re: thttpd question (TCP close problem?)
Posted by Adam Feuer <ad...@starcat.io>.
Greg,
Ok, thanks. I did do that yesterday with tcpdump while trying to find the
closing-early problem with the header lengths. Now with the header length
calculation things look good– at low speeds, the packet exchange matches
what I am getting from a Linux web server. No retransmissions, resets, or
missed ACKs. I will try a high-speed capture and examine it.
I did try tcpblaster last night, and can only get about 100 KB/s maximum –
about 800kbps, so much less than the 480Mbps that's possible. So that is
probably part of the constraint. The SAMA5D36 has USB DMA.so it should be
possible to get 100Mbps or higher... I will try with the Gigabit Ethernet
and see if I can find the bottleneck.
-adam
On Sun, Jan 12, 2020 at 11:07 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> >> The first thing I would do would be to use Wireshark to see what exactly
> >> the timing on the network is.
> >>
> > Greg,
> >
> > Thanks- that sounds good. Would you be willing to say more about this?
> What
> > exactly would you look for?
>
> You should see the connection, the HTTP requests and the HTTP responses,
> and the socket close sequence. More importantly, you will see the times
> between them and if there is anything weird going on like retransmissions.
>
>
>
--
Adam Feuer <ad...@starcat.io>
Re: thttpd question (TCP close problem?)
Posted by Gregory Nutt <sp...@gmail.com>.
>> The first thing I would do would be to use Wireshark to see what exactly
>> the timing on the network is.
>>
> Greg,
>
> Thanks- that sounds good. Would you be willing to say more about this? What
> exactly would you look for?
You should see the connection, the HTTP requests and the HTTP responses,
and the socket close sequence. More importantly, you will see the times
between them and if there is anything weird going on like retransmissions.
Re: thttpd question (TCP close problem?)
Posted by Adam Feuer <ad...@starcat.io>.
> The first thing I would do would be to use Wireshark to see what exactly
> the timing on the network is.
>
Greg,
Thanks- that sounds good. Would you be willing to say more about this? What
exactly would you look for?
I also plan to hook up a gigabit Ethernet from the board to my laptop to
see if that has a higher speed, and also use the USB CDC ECM gadget with a
Raspberry Pi Zero– I got the RPi's gadget driver working the other day
while debugging the NuttX gadget driver. I want to see the differences in
these setups.
cheers
adam
--
Adam Feuer <ad...@starcat.io>
Re: thttpd question (TCP close problem?)
Posted by Gregory Nutt <sp...@gmail.com>.
> It was a bug in thttpd – it wasn't accounting for the length of the headers
> properly. I'll make a PR for it once I get a few other issues worked out.
>
> The thttpd performance is a lot worse then uIP webserver– this shouldn't be
> the case. Maybe there is a resource bottleneck of some kind. I tried
> adjusting some of the config settings for sockets/file descriptors/etc. but
> haven't had any luck. I might have to profile the app.
The first thing I would do would be to use Wireshark to see what exactly
the timing on the network is.
Re: thttpd question (TCP close problem?)
Posted by Adam Feuer <ad...@starcat.io>.
It was a bug in thttpd – it wasn't accounting for the length of the headers
properly. I'll make a PR for it once I get a few other issues worked out.
The thttpd performance is a lot worse then uIP webserver– this shouldn't be
the case. Maybe there is a resource bottleneck of some kind. I tried
adjusting some of the config settings for sockets/file descriptors/etc. but
haven't had any luck. I might have to profile the app.
-adam
On Sat, Jan 11, 2020 at 7:12 PM Adam Feuer <ad...@starcat.io> wrote:
> I am thinking it's not the TCP close problem... I'm debugging, it's
> starting to look like thttpd is always closing the connection just short of
> the end of the file. The number of missing bytes equal the length of the
> header bytes returned.
>
> So the bug seems to be in thttpd. I'm trying to track it down.
>
> -adam
>
> On Sat, Jan 11, 2020 at 12:51 PM Adam Feuer <ad...@starcat.io> wrote:
>
>> Xiang,
>>
>> It looks like connection is still not getting closed correctly. 10.0.0.1
>> is my linux box. 10.0.0.2 is the nuttx box. Here's the end of a correct
>> close sequence to a Linux webserver:
>>
>> sudo tcpdump -n -v dst 10.0.0.1 and 'tcp[tcpflags] &
>>> (tcp-syn|tcp-ack|tcp-fin) > 0' -i lo
>>>
>>
>>
>>> 12:38:41.185547 IP (tos 0x0, ttl 64, id 34591, offset 0, flags [DF],
>>> proto TCP (6), length 52)
>>> 10.0.0.1.38890 > 10.0.0.1.80: Flags [.], cksum 0x1428 (incorrect ->
>>> 0x7a03), ack 860, win 506, options [nop,nop,TS val 3777231081 ecr
>>> 3777231081], length 0
>>> 12:38:41.188600 IP (tos 0x0, ttl 64, id 34592, offset 0, flags [DF],
>>> proto TCP (6), length 52)
>>> 10.0.0.1.38890 > 10.0.0.1.80: Flags [F.], cksum 0x1428 (incorrect ->
>>> 0x79f9), seq 73, ack 860, win 512, options [nop,nop,TS val 3777231084 ecr
>>> 3777231081], length 0
>>> 12:38:41.188652 IP (tos 0x0, ttl 64, id 52719, offset 0, flags [DF],
>>> proto TCP (6), length 52)
>>> 10.0.0.1.80 > 10.0.0.1.38890: Flags [F.], cksum 0x1428 (incorrect ->
>>> 0x79f5), seq 860, ack 74, win 512, options [nop,nop,TS val 3777231084 ecr
>>> 3777231084], length 0
>>> 12:38:41.188658 IP (tos 0x0, ttl 64, id 34593, offset 0, flags [DF],
>>> proto TCP (6), length 52)
>>> 10.0.0.1.38890 > 10.0.0.1.80: Flags [.], cksum 0x1428 (incorrect ->
>>> 0x79f5), ack 861, win 512, options [nop,nop,TS val 3777231084 ecr
>>> 3777231084], length 0
>>>
>>
>> Here's the end of the incorrectly closed connection to thttpd on nuttx:
>>
>> sudo tcpdump -n -v dst 10.0.0.2 and 'tcp[tcpflags] &
>>> (tcp-syn|tcp-ack|tcp-fin) > 0' -i ens35u2
>>>
>>
>>
>>> 10.0.0.1.45220 > 10.0.0.2.80: Flags [.], cksum 0xc8dc (correct), ack
>>> 1025, win 64368, length 0
>>> 12:40:15.542783 IP (tos 0x0, ttl 64, id 19580, offset 0, flags [DF],
>>> proto TCP (6), length 40)
>>> 10.0.0.1.45220 > 10.0.0.2.80: Flags [.], cksum 0xc8dc (correct), ack
>>> 1281, win 64112, length 0
>>> 12:40:15.787920 IP (tos 0x0, ttl 64, id 19581, offset 0, flags [DF],
>>> proto TCP (6), length 40)
>>> 10.0.0.1.45220 > 10.0.0.2.80: Flags [F.], cksum 0xc5f2 (correct),
>>> seq 72, ack 1282, win 64856, length 0
>>>
>>
>> So it looks like the nuttx box is closing the TCP connection without
>> waiting for the right FIN/ACK sequence.
>>
>> -adam
>>
>> On Sat, Jan 11, 2020 at 12:02 PM Adam Feuer <ad...@starcat.io> wrote:
>>
>>> Xiang Xiao,
>>>
>>> Thanks for the PR, I updated to the latest master since this has been
>>> merged, and I tried it. I am getting a different error now:
>>>
>>> * Closing connection 0
>>> curl: (18) transfer closed with 226 bytes remaining to read
>>>
>>> I tried removing CONFIG_NET_TCP_READAHEAD from my config too, with the
>>> same result.
>>>
>>> It looks like the connection is now being prematurely closed, rather
>>> than not being closed at all. Do you have advice on how to fix this? Or
>>> where to look?
>>>
>>> cheers
>>> adam
>>>
>>> On Sat, Jan 11, 2020 at 12:08 AM Xiang Xiao <xi...@gmail.com>
>>> wrote:
>>>
>>>> On Sat, Jan 11, 2020 at 12:42 PM Adam Feuer <ad...@starcat.io> wrote:
>>>> >
>>>> > After debugging, it seems like the TCP connection is not being closed
>>>> > correctly, and the client receive times out.
>>>> >
>>>> > Could this be the TCP close problem that has been reported? When was
>>>> it
>>>> > introduced? I'd like to go back to a previous version and see if that
>>>> works
>>>> > correctly.
>>>> >
>>>>
>>>> Yes, Rob report the same issue here:
>>>> https://groups.google.com/forum/#!topic/nuttx/nF0pfDkd3hA
>>>> The fix is here:
>>>> https://github.com/apache/incubator-nuttx/pull/76
>>>> Please try it.
>>>>
>>>> > -adam
>>>> >
>>>> > On Fri, Jan 10, 2020 at 16:32 Adam Feuer <ad...@starcat.io> wrote:
>>>> >
>>>> > > Hi,
>>>> > >
>>>> > > I got the uIP webserver example to work on the SAMA5D36-Xplained.
>>>> However,
>>>> > > it's not fast enough for my needs. (Probably to be expected since
>>>> it's
>>>> > > designed for low-power devices.)
>>>> > >
>>>> > > I am trying to get the thttpd example to work. It compiles, and I
>>>> can run
>>>> > > the thttp command from the NuttX shell. It will serve about 75% of
>>>> the
>>>> > > index page, and then appears to hang– the page never finishes
>>>> transmission.
>>>> > > I'm going to debug, but I thought I'd ask:
>>>> > >
>>>> > > Has anyone seen this before? If so, what's wrong and how do I fix
>>>> it?
>>>> > >
>>>> > > cheers
>>>> > > adam
>>>> > > --
>>>> > > Adam Feuer <ad...@starcat.io>
>>>> > >
>>>> > --
>>>> > Adam Feuer <ad...@starcat.io>
>>>>
>>>
>>>
>>> --
>>> Adam Feuer <ad...@starcat.io>
>>>
>>
>>
>> --
>> Adam Feuer <ad...@starcat.io>
>>
>
>
> --
> Adam Feuer <ad...@starcat.io>
>
--
Adam Feuer <ad...@starcat.io>
Re: thttpd question (TCP close problem?)
Posted by Adam Feuer <ad...@starcat.io>.
I am thinking it's not the TCP close problem... I'm debugging, it's
starting to look like thttpd is always closing the connection just short of
the end of the file. The number of missing bytes equal the length of the
header bytes returned.
So the bug seems to be in thttpd. I'm trying to track it down.
-adam
On Sat, Jan 11, 2020 at 12:51 PM Adam Feuer <ad...@starcat.io> wrote:
> Xiang,
>
> It looks like connection is still not getting closed correctly. 10.0.0.1
> is my linux box. 10.0.0.2 is the nuttx box. Here's the end of a correct
> close sequence to a Linux webserver:
>
> sudo tcpdump -n -v dst 10.0.0.1 and 'tcp[tcpflags] &
>> (tcp-syn|tcp-ack|tcp-fin) > 0' -i lo
>>
>
>
>> 12:38:41.185547 IP (tos 0x0, ttl 64, id 34591, offset 0, flags [DF],
>> proto TCP (6), length 52)
>> 10.0.0.1.38890 > 10.0.0.1.80: Flags [.], cksum 0x1428 (incorrect ->
>> 0x7a03), ack 860, win 506, options [nop,nop,TS val 3777231081 ecr
>> 3777231081], length 0
>> 12:38:41.188600 IP (tos 0x0, ttl 64, id 34592, offset 0, flags [DF],
>> proto TCP (6), length 52)
>> 10.0.0.1.38890 > 10.0.0.1.80: Flags [F.], cksum 0x1428 (incorrect ->
>> 0x79f9), seq 73, ack 860, win 512, options [nop,nop,TS val 3777231084 ecr
>> 3777231081], length 0
>> 12:38:41.188652 IP (tos 0x0, ttl 64, id 52719, offset 0, flags [DF],
>> proto TCP (6), length 52)
>> 10.0.0.1.80 > 10.0.0.1.38890: Flags [F.], cksum 0x1428 (incorrect ->
>> 0x79f5), seq 860, ack 74, win 512, options [nop,nop,TS val 3777231084 ecr
>> 3777231084], length 0
>> 12:38:41.188658 IP (tos 0x0, ttl 64, id 34593, offset 0, flags [DF],
>> proto TCP (6), length 52)
>> 10.0.0.1.38890 > 10.0.0.1.80: Flags [.], cksum 0x1428 (incorrect ->
>> 0x79f5), ack 861, win 512, options [nop,nop,TS val 3777231084 ecr
>> 3777231084], length 0
>>
>
> Here's the end of the incorrectly closed connection to thttpd on nuttx:
>
> sudo tcpdump -n -v dst 10.0.0.2 and 'tcp[tcpflags] &
>> (tcp-syn|tcp-ack|tcp-fin) > 0' -i ens35u2
>>
>
>
>> 10.0.0.1.45220 > 10.0.0.2.80: Flags [.], cksum 0xc8dc (correct), ack
>> 1025, win 64368, length 0
>> 12:40:15.542783 IP (tos 0x0, ttl 64, id 19580, offset 0, flags [DF],
>> proto TCP (6), length 40)
>> 10.0.0.1.45220 > 10.0.0.2.80: Flags [.], cksum 0xc8dc (correct), ack
>> 1281, win 64112, length 0
>> 12:40:15.787920 IP (tos 0x0, ttl 64, id 19581, offset 0, flags [DF],
>> proto TCP (6), length 40)
>> 10.0.0.1.45220 > 10.0.0.2.80: Flags [F.], cksum 0xc5f2 (correct), seq
>> 72, ack 1282, win 64856, length 0
>>
>
> So it looks like the nuttx box is closing the TCP connection without
> waiting for the right FIN/ACK sequence.
>
> -adam
>
> On Sat, Jan 11, 2020 at 12:02 PM Adam Feuer <ad...@starcat.io> wrote:
>
>> Xiang Xiao,
>>
>> Thanks for the PR, I updated to the latest master since this has been
>> merged, and I tried it. I am getting a different error now:
>>
>> * Closing connection 0
>> curl: (18) transfer closed with 226 bytes remaining to read
>>
>> I tried removing CONFIG_NET_TCP_READAHEAD from my config too, with the
>> same result.
>>
>> It looks like the connection is now being prematurely closed, rather than
>> not being closed at all. Do you have advice on how to fix this? Or where to
>> look?
>>
>> cheers
>> adam
>>
>> On Sat, Jan 11, 2020 at 12:08 AM Xiang Xiao <xi...@gmail.com>
>> wrote:
>>
>>> On Sat, Jan 11, 2020 at 12:42 PM Adam Feuer <ad...@starcat.io> wrote:
>>> >
>>> > After debugging, it seems like the TCP connection is not being closed
>>> > correctly, and the client receive times out.
>>> >
>>> > Could this be the TCP close problem that has been reported? When was it
>>> > introduced? I'd like to go back to a previous version and see if that
>>> works
>>> > correctly.
>>> >
>>>
>>> Yes, Rob report the same issue here:
>>> https://groups.google.com/forum/#!topic/nuttx/nF0pfDkd3hA
>>> The fix is here:
>>> https://github.com/apache/incubator-nuttx/pull/76
>>> Please try it.
>>>
>>> > -adam
>>> >
>>> > On Fri, Jan 10, 2020 at 16:32 Adam Feuer <ad...@starcat.io> wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > I got the uIP webserver example to work on the SAMA5D36-Xplained.
>>> However,
>>> > > it's not fast enough for my needs. (Probably to be expected since
>>> it's
>>> > > designed for low-power devices.)
>>> > >
>>> > > I am trying to get the thttpd example to work. It compiles, and I
>>> can run
>>> > > the thttp command from the NuttX shell. It will serve about 75% of
>>> the
>>> > > index page, and then appears to hang– the page never finishes
>>> transmission.
>>> > > I'm going to debug, but I thought I'd ask:
>>> > >
>>> > > Has anyone seen this before? If so, what's wrong and how do I fix it?
>>> > >
>>> > > cheers
>>> > > adam
>>> > > --
>>> > > Adam Feuer <ad...@starcat.io>
>>> > >
>>> > --
>>> > Adam Feuer <ad...@starcat.io>
>>>
>>
>>
>> --
>> Adam Feuer <ad...@starcat.io>
>>
>
>
> --
> Adam Feuer <ad...@starcat.io>
>
--
Adam Feuer <ad...@starcat.io>
Re: thttpd question (TCP close problem?)
Posted by Adam Feuer <ad...@starcat.io>.
Xiang,
It looks like connection is still not getting closed correctly. 10.0.0.1 is
my linux box. 10.0.0.2 is the nuttx box. Here's the end of a correct close
sequence to a Linux webserver:
sudo tcpdump -n -v dst 10.0.0.1 and 'tcp[tcpflags] &
> (tcp-syn|tcp-ack|tcp-fin) > 0' -i lo
>
> 12:38:41.185547 IP (tos 0x0, ttl 64, id 34591, offset 0, flags [DF], proto
> TCP (6), length 52)
> 10.0.0.1.38890 > 10.0.0.1.80: Flags [.], cksum 0x1428 (incorrect ->
> 0x7a03), ack 860, win 506, options [nop,nop,TS val 3777231081 ecr
> 3777231081], length 0
> 12:38:41.188600 IP (tos 0x0, ttl 64, id 34592, offset 0, flags [DF], proto
> TCP (6), length 52)
> 10.0.0.1.38890 > 10.0.0.1.80: Flags [F.], cksum 0x1428 (incorrect ->
> 0x79f9), seq 73, ack 860, win 512, options [nop,nop,TS val 3777231084 ecr
> 3777231081], length 0
> 12:38:41.188652 IP (tos 0x0, ttl 64, id 52719, offset 0, flags [DF], proto
> TCP (6), length 52)
> 10.0.0.1.80 > 10.0.0.1.38890: Flags [F.], cksum 0x1428 (incorrect ->
> 0x79f5), seq 860, ack 74, win 512, options [nop,nop,TS val 3777231084 ecr
> 3777231084], length 0
> 12:38:41.188658 IP (tos 0x0, ttl 64, id 34593, offset 0, flags [DF], proto
> TCP (6), length 52)
> 10.0.0.1.38890 > 10.0.0.1.80: Flags [.], cksum 0x1428 (incorrect ->
> 0x79f5), ack 861, win 512, options [nop,nop,TS val 3777231084 ecr
> 3777231084], length 0
>
Here's the end of the incorrectly closed connection to thttpd on nuttx:
sudo tcpdump -n -v dst 10.0.0.2 and 'tcp[tcpflags] &
> (tcp-syn|tcp-ack|tcp-fin) > 0' -i ens35u2
>
> 10.0.0.1.45220 > 10.0.0.2.80: Flags [.], cksum 0xc8dc (correct), ack
> 1025, win 64368, length 0
> 12:40:15.542783 IP (tos 0x0, ttl 64, id 19580, offset 0, flags [DF], proto
> TCP (6), length 40)
> 10.0.0.1.45220 > 10.0.0.2.80: Flags [.], cksum 0xc8dc (correct), ack
> 1281, win 64112, length 0
> 12:40:15.787920 IP (tos 0x0, ttl 64, id 19581, offset 0, flags [DF], proto
> TCP (6), length 40)
> 10.0.0.1.45220 > 10.0.0.2.80: Flags [F.], cksum 0xc5f2 (correct), seq
> 72, ack 1282, win 64856, length 0
>
So it looks like the nuttx box is closing the TCP connection without
waiting for the right FIN/ACK sequence.
-adam
On Sat, Jan 11, 2020 at 12:02 PM Adam Feuer <ad...@starcat.io> wrote:
> Xiang Xiao,
>
> Thanks for the PR, I updated to the latest master since this has been
> merged, and I tried it. I am getting a different error now:
>
> * Closing connection 0
> curl: (18) transfer closed with 226 bytes remaining to read
>
> I tried removing CONFIG_NET_TCP_READAHEAD from my config too, with the
> same result.
>
> It looks like the connection is now being prematurely closed, rather than
> not being closed at all. Do you have advice on how to fix this? Or where to
> look?
>
> cheers
> adam
>
> On Sat, Jan 11, 2020 at 12:08 AM Xiang Xiao <xi...@gmail.com>
> wrote:
>
>> On Sat, Jan 11, 2020 at 12:42 PM Adam Feuer <ad...@starcat.io> wrote:
>> >
>> > After debugging, it seems like the TCP connection is not being closed
>> > correctly, and the client receive times out.
>> >
>> > Could this be the TCP close problem that has been reported? When was it
>> > introduced? I'd like to go back to a previous version and see if that
>> works
>> > correctly.
>> >
>>
>> Yes, Rob report the same issue here:
>> https://groups.google.com/forum/#!topic/nuttx/nF0pfDkd3hA
>> The fix is here:
>> https://github.com/apache/incubator-nuttx/pull/76
>> Please try it.
>>
>> > -adam
>> >
>> > On Fri, Jan 10, 2020 at 16:32 Adam Feuer <ad...@starcat.io> wrote:
>> >
>> > > Hi,
>> > >
>> > > I got the uIP webserver example to work on the SAMA5D36-Xplained.
>> However,
>> > > it's not fast enough for my needs. (Probably to be expected since it's
>> > > designed for low-power devices.)
>> > >
>> > > I am trying to get the thttpd example to work. It compiles, and I can
>> run
>> > > the thttp command from the NuttX shell. It will serve about 75% of the
>> > > index page, and then appears to hang– the page never finishes
>> transmission.
>> > > I'm going to debug, but I thought I'd ask:
>> > >
>> > > Has anyone seen this before? If so, what's wrong and how do I fix it?
>> > >
>> > > cheers
>> > > adam
>> > > --
>> > > Adam Feuer <ad...@starcat.io>
>> > >
>> > --
>> > Adam Feuer <ad...@starcat.io>
>>
>
>
> --
> Adam Feuer <ad...@starcat.io>
>
--
Adam Feuer <ad...@starcat.io>
Re: thttpd question (TCP close problem?)
Posted by Adam Feuer <ad...@starcat.io>.
Xiang Xiao,
Thanks for the PR, I updated to the latest master since this has been
merged, and I tried it. I am getting a different error now:
* Closing connection 0
curl: (18) transfer closed with 226 bytes remaining to read
I tried removing CONFIG_NET_TCP_READAHEAD from my config too, with the same
result.
It looks like the connection is now being prematurely closed, rather than
not being closed at all. Do you have advice on how to fix this? Or where to
look?
cheers
adam
On Sat, Jan 11, 2020 at 12:08 AM Xiang Xiao <xi...@gmail.com>
wrote:
> On Sat, Jan 11, 2020 at 12:42 PM Adam Feuer <ad...@starcat.io> wrote:
> >
> > After debugging, it seems like the TCP connection is not being closed
> > correctly, and the client receive times out.
> >
> > Could this be the TCP close problem that has been reported? When was it
> > introduced? I'd like to go back to a previous version and see if that
> works
> > correctly.
> >
>
> Yes, Rob report the same issue here:
> https://groups.google.com/forum/#!topic/nuttx/nF0pfDkd3hA
> The fix is here:
> https://github.com/apache/incubator-nuttx/pull/76
> Please try it.
>
> > -adam
> >
> > On Fri, Jan 10, 2020 at 16:32 Adam Feuer <ad...@starcat.io> wrote:
> >
> > > Hi,
> > >
> > > I got the uIP webserver example to work on the SAMA5D36-Xplained.
> However,
> > > it's not fast enough for my needs. (Probably to be expected since it's
> > > designed for low-power devices.)
> > >
> > > I am trying to get the thttpd example to work. It compiles, and I can
> run
> > > the thttp command from the NuttX shell. It will serve about 75% of the
> > > index page, and then appears to hang– the page never finishes
> transmission.
> > > I'm going to debug, but I thought I'd ask:
> > >
> > > Has anyone seen this before? If so, what's wrong and how do I fix it?
> > >
> > > cheers
> > > adam
> > > --
> > > Adam Feuer <ad...@starcat.io>
> > >
> > --
> > Adam Feuer <ad...@starcat.io>
>
--
Adam Feuer <ad...@starcat.io>
Re: thttpd question (TCP close problem?)
Posted by Xiang Xiao <xi...@gmail.com>.
On Sat, Jan 11, 2020 at 12:42 PM Adam Feuer <ad...@starcat.io> wrote:
>
> After debugging, it seems like the TCP connection is not being closed
> correctly, and the client receive times out.
>
> Could this be the TCP close problem that has been reported? When was it
> introduced? I'd like to go back to a previous version and see if that works
> correctly.
>
Yes, Rob report the same issue here:
https://groups.google.com/forum/#!topic/nuttx/nF0pfDkd3hA
The fix is here:
https://github.com/apache/incubator-nuttx/pull/76
Please try it.
> -adam
>
> On Fri, Jan 10, 2020 at 16:32 Adam Feuer <ad...@starcat.io> wrote:
>
> > Hi,
> >
> > I got the uIP webserver example to work on the SAMA5D36-Xplained. However,
> > it's not fast enough for my needs. (Probably to be expected since it's
> > designed for low-power devices.)
> >
> > I am trying to get the thttpd example to work. It compiles, and I can run
> > the thttp command from the NuttX shell. It will serve about 75% of the
> > index page, and then appears to hang– the page never finishes transmission.
> > I'm going to debug, but I thought I'd ask:
> >
> > Has anyone seen this before? If so, what's wrong and how do I fix it?
> >
> > cheers
> > adam
> > --
> > Adam Feuer <ad...@starcat.io>
> >
> --
> Adam Feuer <ad...@starcat.io>