From owner-freebsd-net@FreeBSD.ORG Mon Jan 8 10:36:45 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71C5516A412 for ; Mon, 8 Jan 2007 10:36:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 289B913C46C for ; Mon, 8 Jan 2007 10:36:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1H3rrs-000I4d-WA; Mon, 08 Jan 2007 13:36:41 +0300 Date: Mon, 8 Jan 2007 13:36:36 +0300 From: Eygene Ryabinkin To: Tadaaki Nagao Message-ID: <20070108103635.GI37482@codelabs.ru> References: <459D4D88.2030708@delphij.net> <20070105113442.GH37482@codelabs.ru> <20070105162022.GA1503@twilight.mbslab.kiae.ru> <20070108.175354.26933985.nagao@iij.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070108.175354.26933985.nagao@iij.ad.jp> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_20 Cc: freebsd-net@freebsd.org, andre@FreeBSD.org, delphij@delphij.net Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? 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: Mon, 08 Jan 2007 10:36:45 -0000 Tadaaki, good day! > This seems to be the same problem as kern/99558: "FreeBSD 6.1 can't send > packets to INADDR_BROADCAST". > > Maybe andre has some thoughts on how to fix this issue? (I'm CC'ing him.) Exactly, thank you very much for the pointer! > It seems to me from the PR above, that before patching `ping', ip_output.c > should receive some sort of fix in handling INADDR_BROADCAST. If ip_output.c will receive patching, it probably will be unneccessary to patch `ping' ;)) The problem with ip_output.c patch is that it is rather hard to spot the right interface to output the broadcast to: no pointers are given when the packet just destined to 255.255.255.255. Probably the best way will be to - output it to all interfaces with broadcast capability, - limit the TTL to 1. The patch for `ping' introduces '-b' flag namely for the purpose of identifying the interface the broadcast will go to. -- Eygene