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
adj
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 d
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.1
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
I fixed this section of code because it had ETIMEOUT instead of
ETIMEDOUT and so caused a compilation failure.
Looking more carefully, net_timedwait() will return -ETIMEDOUT on the
timeout. So shouldn't the condition be (ret == -ETIMEDOUT && acked ==
state.snd_acked). I will change the cod
I fixed this section of code because it had ETIMEOUT instead of
ETIMEDOUT and so caused a compilation failure.
Looking more carefully, net_timedwait() will return -ETIMEDOUT on the
timeout. So shouldn't the condition be (ret == -ETIMEDOUT && acked ==
state.snd_acked). I will change the code
On Sat, Jan 11, 2020 at 12:42 PM Adam Feuer 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 ve
