From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 13:00:33 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C02B16A41F for ; Fri, 14 Oct 2005 13:00:33 +0000 (GMT) (envelope-from Nicolas.Kowalski@imag.fr) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D546143D45 for ; Fri, 14 Oct 2005 13:00:32 +0000 (GMT) (envelope-from Nicolas.Kowalski@imag.fr) Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j9ED0UNV004610 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 14 Oct 2005 15:00:30 +0200 (CEST) Received: from obiou.imag.fr ([129.88.43.2]) by mail-veri.imag.fr with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EQPAk-0008Rz-Ai for freebsd-net@FreeBSD.org; Fri, 14 Oct 2005 15:00:30 +0200 Received: from kowalski by obiou.imag.fr with local (Exim 4.50) id 1EQPAk-0001oW-5s for freebsd-net@FreeBSD.org; Fri, 14 Oct 2005 15:00:30 +0200 To: freebsd-net@FreeBSD.org References: <20051014160128.hev160v52ossokg0@wwws.cs.ait.ac.th> <20051014045824.V5343@odysseus.silby.com> From: Nicolas KOWALSKI Date: Fri, 14 Oct 2005 15:00:30 +0200 In-Reply-To: <20051014045824.V5343@odysseus.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Nicolas Kowalski X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Fri, 14 Oct 2005 15:00:30 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information Cc: Subject: Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 13:00:33 -0000 Mike Silbersack writes: > On Fri, 14 Oct 2005, on@cs.ait.ac.th wrote: > >> Nicolas KOWALSKI wrote: >>> Our FreeBSD 4.10 NFS server has some problems serving files by NFS >>> on TCP (no problem with UDP) when the Linux (2.6) or Solaris (5.9) >>> clients shut down in an unclean manner (power failure). When the >>> clients try to mount the shares from the server after an unclean >>> shutdown, the mount process hang during several minutes (delay is >>> varying), then succeeds. >> >> That is just a wild guess, but NFS mounting would happen always at >> the same stage of the boot, so maybe with the same source port >> number and you could be facing the problem that the connection is >> waiting for termination on the server (close_wait or fin_wait or >> something)... Se source port in working example is 798 and source >> port in failing example is 799 certainly not random. > > The socket on the server would still be in the ESTABLISHED state, > which is even worse than the close_wait or fin_wait states in this > case. The SYN will be accepted if it's greater than the previous > sequence number, so that's a 50% chance it'll work. Thanks for this explanation. > Assuming that port reuse is the problem, there is no quick fix for > this, just resetting connections when a SYN comes in would be a > really big security problem. Really? Are Linux and Solaris that insecure because of this behaviour? > Actually, there may be a quick fix for this specific machine. If you > set net.inet.tcp.keepidle to 1 minute (60*whatever kern.hz is), > that'll cause keepalive packets to be sent every minute to an idle > connection, rather than every 2 hours. That would kill the stuck > connections much quicker. Unfortunately, this does not work as expected. I just tested with my workstation (Linux 2.6), with NFS filesystems mounted with TCP; when the station rebooted abruptely, mounting the same NFS filesystems hung more than 1 minute (15 minutes just now). During this hang, I saw on the server, using netstat, the nfsd process related to my workstation in ESTABLISHED state. Any other tip? Many Thanks in advance, -- Nicolas