All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Kalogirou <harkal@gmx.net>
To: jb1@btstream.com
Cc: Linux-8086 <linux-8086@vger.kernel.org>
Subject: Re: [SOLVED] Re: webserver stalls [was Re: bug in (linux) slattach]
Date: 29 Oct 2002 14:37:27 +0200	[thread overview]
Message-ID: <1035894974.8585.171.camel@cool> (raw)
In-Reply-To: <Pine.LNX.4.33.0210290142240.25949-100000@olympus.btstream.com>

> On 22 Oct 2002, Harry Kalogirou wrote:
> 
> > > Ok the quest is over.
> 
> Not yet. I think _tcp_chksumraw in tcp_output.c needs the same fixes as 
> those you applied to _tcp_chksum. Without them I still got partial files 
> with telnet/get.

It is fixed.
 
> There's *still* something wrong, but it shows up most frequently when I 
> urlget from one ELKS box to another (yes, they have different IP 
> addresses). Rarely, all goes as it should; more often, the entire file 
> comes in a reasonable time, but I never get the command prompt; often, 
> nothing comes in and I never get the command prompt. Once, nothing seemed 
> to happen for about 10 minutes, but when I checked the machines about 10 
> minutes later, the file had come in but there was no command prompt. I had 
> enabled a second getty on that machine, so I was able to log in and run 
> netstat on both machines while urlget was hung. Here are the results 
> (about an hour later):
> 
> On the client ("urlget") machine (192.168.1.100) --
> 1 ESTABLISHED 4000ms 1025       0.0.0.0  2
> 2 ESTABLISHED 2400ms 1024 192.168.1.144 80
> 3      LISTEN 4000MS   80       0.0.0.0  0
> 
> 
> On the server ("sender") (1.2.168.1.144) --
> 1 ESTABLISHED 4000ms 1024       0.0.0.0  2
> 2      LISTEN 4000ms   80       0.0.0.0  0
> 
> Obviously, the server has discarded the connection, but the client machine
> thinks it's still connected.
> 
> I'm also not sure the client port number (the one that's 1024 or greater) 
> is handled properly. Each time I connect from a Linux box the port number 
> is incremented, but once I observered that a first, successful, connection 
> from ELKS was from port 1024, and the next, hanging, attempt was *also* 
> port 1024. Connections from Linux usually, but not always, work; 
> connections from ELKS rarely work.

ELKS reuses the last used port if it is not still in use. I don't think
that this is a problem. 

> Diagnosing this stuff is very time-consuming because "kill" doesn't seem 
> to do anything, so I must reboot both machines. Since ELKS "telnet" 

The kernel in the CVS will probably handle this more gracefully and
actualy the process.

> doesn't do anything but connect (and logs me out when it terminates!) I 
> can't compare telnet from Linux and ELKS. I can only compare "urlget" from 
> both systems, and since there's no tcpdump for ELKS I can't even determing 
> if a failure is actually due to urlget.

You mean that you do "telnet bla.bla 80" and after you connect you can't
do "get /"?

Harry





  reply	other threads:[~2002-10-29 12:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1035036158.454.17.camel@cool>
2002-10-20  9:34 ` webserver stalls [was Re: bug in (linux) slattach] jb1
2002-10-20 17:06   ` Harry Kalogirou
2002-10-21  9:44     ` jb1
2002-10-21  9:55       ` Harry Kalogirou
2002-10-22 10:16         ` jb1
2002-10-22 13:56           ` Harry Kalogirou
2002-10-22 13:57           ` [SOLVED] " Harry Kalogirou
2002-10-22 16:02             ` Harry Kalogirou
2002-10-23  9:37               ` jb1
2002-10-23 11:42                 ` Harry Kalogirou
2002-10-24  8:55                   ` jb1
2002-10-29 10:25               ` jb1
2002-10-29 12:37                 ` Harry Kalogirou [this message]
     [not found] <Pine.LNX.4.33.0210300110270.32451-100000@olympus.btstream.com>
2002-10-30 10:31 ` Harry Kalogirou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1035894974.8585.171.camel@cool \
    --to=harkal@gmx.net \
    --cc=jb1@btstream.com \
    --cc=linux-8086@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.