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>
