Re: webserver stalls [was Re: bug in (linux) slattach]

jb1
2002-10-20T09:34:56Z

On 19 Oct 2002, Harry Kalogirou wrote:

>
> Since I had used ELKS for long time on my network and I hardly had
> checksum errors, had other biger problems 8), I think that this has

From what I've seen in the mailinglist archives, I think other people have
had similar problems. They probably just gave up when no one answered
their vague, sometimes irrelevant, questions.

> something to do with the serial line altering bytes that ELKS transmits.
> Can you send me the output of "stty -a -F /dev/ttySX" after you setup
> the connection. Maybe the line is not corectly setup on linux side (XOFF
> XON and stuff).

After issuing "/bin/stty -F /dev/ttyS0 4800" on the Red Hat 7.0 Linux box,
"stty -a -F /dev/ttyS0" displays:
speed 4800 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
-ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
-echoprt
echoctl echoke

> If the above proves the setup of the serial line to be ok, then ELKS has
> a problem. Maybe then the problem is at the assembly optimized checksum
> routines I wrote. Disabling that by undefing USE_ASM in ip.c will show
> that.

Both the C and ASM routines in ip_calc_chksum() in elksnet/ktcp/ip.c from
elksnet-0.1.1.tar.gz look like they should have worked correctly for the
packet with the bad IP Header checksum. The C routine has a lurking bug;
it doesn't account for a possible carry in
return ~((sum & 0xffff) + ((sum >> 16) & 0xffff));
but even if USE_ASM were undefined it wouldn't have affected that packet.

Even if my serial port handshaking is incorrecty set up, the difference
between the packet that fails and the one that succeeds is trivial. The
former is 63 bytes long with the data "Content-Length: 100^M^J^M^J"; the
latter is 62 bytes long with the data "Content-Length: 99^M^J^M^J and
(after the ACK by the linux box) is followed by a *successful* 139-byte
packet containing the entire 99-byte webpage file. Also, the erroneous
checksum is exactly the same and in exactly the same packet even for the
266-byte original file tcpdump'ed several days earlier ("Content-Length:
266^M^J^M^J"). The Linux box's /proc/cpuinfo says its AMD-K6 is running at
360.800 MHz; I wouldn't be surprised if it could run 4800 baud with no
handshaking at all, and I didn't notice any XON or XOFF characters mixed
in with the data.

I wonder if there's any significance in the fact that the problem occurs
precisely at the boundary between data obviously generated by the server,
itself, and the contents of the webpage file.