From owner-freebsd-stable@FreeBSD.ORG Tue Jun 29 15:12:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 995A61065670 for ; Tue, 29 Jun 2010 15:12:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 45D178FC19 for ; Tue, 29 Jun 2010 15:12:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUGAJeqKUyDaFvJ/2dsb2JhbACTDIw3ccAHhSQE X-IronPort-AV: E=Sophos;i="4.53,505,1272859200"; d="scan'208";a="82115123" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 29 Jun 2010 11:12:07 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id EA559FB8012; Tue, 29 Jun 2010 11:12:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-XUAc4uPIyj; Tue, 29 Jun 2010 11:12:08 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id AF5A0FB80FB; Tue, 29 Jun 2010 11:12:04 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o5TFT1t29396; Tue, 29 Jun 2010 11:29:01 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 29 Jun 2010 11:29:00 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: alexs@ulgsm.ru In-Reply-To: <20100629064902.GA39446@mail.ulgsm.ru> Message-ID: References: <20100625152027.GA78442@mail.ulgsm.ru> <20100626113418.GA80299@mail.ulgsm.ru> <20100628061601.GA51359@mail.ulgsm.ru> <20100628102703.GA78354@mail.ulgsm.ru> <20100629064902.GA39446@mail.ulgsm.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: diskless boot, nfs server behind router X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 15:12:11 -0000 On Tue, 29 Jun 2010, alexs@ulgsm.ru wrote: >> >> I think using NFS_ROOT but not the BOOTPxxx options will work around this >> or you could test the following patch and see if it helps. (Testing the >> patch would be appreciated, since I don't have any way to test across >> multiple subnets and it would be nice to have a fix for the BOOTPxxx >> cases.) >> >> rick >> --- untested patch for bootp_subr.c --- >> --- nfsclient/bootp_subr.c.sav 2010-06-28 19:16:02.000000000 -0400 >> +++ nfsclient/bootp_subr.c 2010-06-28 19:21:52.000000000 -0400 >> @@ -1524,6 +1524,7 @@ >> printf(" "); >> ifctx->gotgw = 1; >> gctx->gotgw = 1; >> + nd->mygateway = ifctx->gw; >> } >> } > > > Yes. without BOOTPxxx options boot is fine. > Ok, so at least you got it working. > > I tryed your path with BOOTPxxx options, result panic. > > Trying to mount root from nfs: > Panic: nfs_mountroot: RTM_ADD: 17 > cpuid=1 > Uptime 10s > Oh well, the patch was just a stab in the dark. The panic indicates that it already has the route set up (17 == EEXIST), so trying to set it again failed and panic'd. So, I don't know why the case with BOOTPxxx options fails to get through the gateway. If you feel like doing so, you could capture a packet trace (via tcpdump, wireshark, ...) after reverting the patch. The easiest way to do this would be to plug the client and another machine that can do the packet capture into an old 10baseT (non-switched) hub. If you don't have one of those, most network switches will allow a port to be "mirrored" (at least I think that's the term used), so that the packets come out on a second port for the machine doing the capturing. You could do a capture at the server end, but it probably wouldn't tell you anything useful (the packets wouldn't show up, is my guess?). Anyhow, thanks for the help tracking this down and we now know NFS_ROOT works for this case and BOOTPxxx doesn't, rick