From owner-freebsd-stable Thu May 20 16:57:35 1999 Delivered-To: freebsd-stable@freebsd.org Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by hub.freebsd.org (Postfix) with SMTP id 88D0914DDF for ; Thu, 20 May 1999 16:57:21 -0700 (PDT) (envelope-from tom@uniserve.com) Received: from shell.uniserve.ca [204.244.186.218] by pop.uniserve.com with smtp (Exim 1.82 #4) id 10kcge-0001vG-00; Thu, 20 May 1999 16:57:16 -0700 Date: Thu, 20 May 1999 16:57:13 -0700 (PDT) From: Tom X-Sender: tom@shell.uniserve.ca To: Kenn Martin Cc: freebsd-stable@freebsd.org Subject: Re: Debugging a stalled connection In-Reply-To: <19990520163439.B15580@infoteam.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 20 May 1999, Kenn Martin wrote: > I have a number of machines running 3.2-STABLE with no problem, except one, > an "old" Pentium 200. It has an Intel PRO/100+ Server Adapter (fxp0), two > IDE disks, and 1 IDE CDROM drive (dmesg below). This also was happening > in later builds of 3.1-STABLE. > > Large transfers, such as an NFS-mount installworld or a ftp get of a file > over approx 1MB, will stall regularly and indefinately. > > No other operation appears to be affected and I can start another ssh > session with the "stalled" machine. > > How should I go about debugging this problem? "netstat -i" will give you interface error counts. "netstat" will the status of all network connections. Check everything between the stalled machine and the client. This includes routers, switches, hubs, and cabling. Check error counters on all intervening equipment. Try switching MTU path discovery off. Misconfigured routers will break MTU discovery. Turn off TCP extensions. Broken routers and clients will not handle TCP extensions properly. > thanks, > kenn Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message