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 <a...@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 <a...@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 <a...@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 <xiaoxiang781...@gmail.com> >>> wrote: >>> >>>> On Sat, Jan 11, 2020 at 12:42 PM Adam Feuer <a...@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 <a...@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 <a...@starcat.io> >>>> > > >>>> > -- >>>> > Adam Feuer <a...@starcat.io> >>>> >>> >>> >>> -- >>> Adam Feuer <a...@starcat.io> >>> >> >> >> -- >> Adam Feuer <a...@starcat.io> >> > > > -- > Adam Feuer <a...@starcat.io> > -- Adam Feuer <a...@starcat.io>
