bug in (linux) slattach
A message that is not in the archive (sent off-list or not yet received): 1034621946.3293.92.camel@cool
Quoted 2 lines · Harry Kalogirou
I don't seem to get what causes the problem. As much as I can see ELKS does the job fine.
I don't get it either. From what you say, ELKS works with everything but Red Hat; as far as I know, Red Hat works with everything but ELKS. What you found is *almost* consistent with something I discovered and reported to the mailing list as "webserver stalls". Essentially, if the Content-Length is less than 100 bytes then lynx and telnet (and, by the way, the Linux version of urlget) work fine, otherwise they all stall. Maybe we're looking in the wrong place. I assume ELKS serial port works properly and I *know* Red Hat's does even for large transfers, but if this were a new system I'd suspect something like this: after the first 100-or-so bytes are received all further incomming bytes are discarded, and the current contents of the buffer are are re-read over and over. I'll have to check it again, but I think "tcpdump -a" is consistent with something like that. Does that suggest anything to you?
Quoted 1 line
Is there any chance that tcpdump even dumps packets with wrong checksum?
I'm not sure, but I thought I read a *complaint* that tcpdump ignored malformed packets. I'll have to look for it again. In light of your interpretation, I'll also study these packets in more detail.
When you were counting bytes, did you notice if ELKS sent all 266 bytes of the default webpage?
Among the *many* things I had to change to get elkscmd to compile correctly was to delete "#include <netdb.h>" from ttn.c because it seemed to be both unnecessary and non-existent. I don't see how, but could that have anything to do with the problem?
Do you know if anyone has or has not encountered this problem using the same versions?
SOURCE PACKAGES:
elks-0.1.1.tar.gz, elkscmd_20020501.tar.gz, elksnet-0.1.1.tar.gz,
Dev86src-0.16.0.tar.gz
CVS PATCHES:
(none)
COMPILED UNDER:
Red Hat 7.0 Linux, kernel 2.2.16-22Re: webserver stalls [was Re: bug in (linux) slattach]
In reply to a message not in the archiveOn 15 Oct 2002, Harry Kalogirou wrote:
...
Quoted 7 lines
Until this point, everything looks ok. The redhat machine send 7 bytes (1 -> 8) and ELKS acknowleged them all. Then ELKS sended the first 100 bytes (1 -> 101) of the page. Redhat ack'ed them too. Then ELKS sends 1 byte (101 -> 102) and Redhat acks it too. The problem starts here....
Quoted 1 line
04:28:17.961776 sl0 < 192.168.1.100.www > 192.168.2.5.1025: P 102:125(23) ack 8 win 512
...
Quoted 3 lines
ELKS continues to send 23 bytes more...
Quoted 1 line
04:28:18.411777 sl0 < 192.168.1.100.www > 192.168.2.5.1025: P 125:225(100) ack 8 win 512
...
Quoted 3 lines
ELKS continues to send 100 bytes more
Quoted 1 line
04:28:18.411835 sl0 > 192.168.2.5.1025 > 192.168.1.100.www: . 8:8(0) ack 102 win 32512 (DF)
...
Quoted 7 lines
and here we have an ack from redhad only for the first 101 bytes again. Not for the 123 extra bytes ELKS send.
I don't seem to get what causes the problem. As much as I can see ELKS does the job fine.
Is there any chance that tcpdump even dumps packets with wrong checksum?
Yes, according to information I found on the web, tcpdump doesn't reject packets with incorrect checksums.
Attached is telnetdumps.zip, which contains sample tcpdumps illustrating how a 99-byte webpage on ELKS succeeds, but two different 100-byte variants stall on my Red Hat 7.0 Linux. Both 100-byte webpages, as well as the original 266-byte sample webpage seem to fail in the same place; specifically, Linux fails to ACK the 23-byte block from ELKS but ELKS continues sending data, while Linux keeps ACK'ing the packet prior to the one with 23 bytes of data. One of the 100-byte variants demonstrates that the problem is not caused by the original webpage's lack of a terminating newline. The file "telnetdumps.jb1" describe the contents in more detail.
I'd like to analyze the packets in more detail, but can't determine the structure. Below is what I've inferred so far; any corrections and additions (especially the checksum location, if any) would be greatly appreciated:
Byte Function
------ ------------------------------------------------------------------
0
1
2-3 packet size
4
5
6
7
8
9
10
11
12-15 source IP address
16-19 destination IP address
20-21 source port
22-23 destination port
24-27 sequence number
28-31 acknowledgement number
32
33
34-35 sender's "win" value
36
37
38
39
40 ... data
I changed the "Subject:" to get this in the appropriate thread.