From owner-freebsd-questions@FreeBSD.ORG Fri Nov 10 15:07:54 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAC8616A403 for ; Fri, 10 Nov 2006 15:07:54 +0000 (UTC) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6555C43D4C for ; Fri, 10 Nov 2006 15:07:54 +0000 (GMT) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: (qmail 30026 invoked from network); 10 Nov 2006 15:07:53 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Nov 2006 15:07:53 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 3BA6C28430; Fri, 10 Nov 2006 10:07:52 -0500 (EST) To: Chris References: <4553E70A.9020501@comcast.net> From: Lowell Gilbert Date: Fri, 10 Nov 2006 10:07:52 -0500 In-Reply-To: <4553E70A.9020501@comcast.net> (Chris's message of "Thu, 09 Nov 2006 18:42:18 -0800") Message-ID: <443b8re3w7.fsf@be-well.ilk.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-questions@freebsd.org Subject: Re: TFTP Problems X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 15:07:54 -0000 Chris writes: > I'm still trying to figure out why the standard tftp won't accept ack > connections from 0.0.0.0. It will recv ack's from a normal IP address > just fine. > > It can't be the firewall because I can set it to "pass all" and > restart with the same results. > > The tftp daemon is started from inetd. The server process is somewhat > different for a inetd daemon as it recieves on socket 0 instead after > it starts. It creates a socket for further communication after it > retries the initial UDP packet sent. It sucessfully sends the first > packet on this socket but it doesn't recv ack's for the packet though > tcpdump see's them come in. The recv timesout and then it resends the > first packet. > > The only thing I can think of is that inetd must initialize it's > sockets in some special way to recieve from 0.0.0.0. 0.0.0.0 is bogus; it's considered a "Martian" address. IP hosts are normally *expected* to ignore them.