From owner-freebsd-net@FreeBSD.ORG Thu Jan 11 06:37:28 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 422FA16A40F; Thu, 11 Jan 2007 06:37:28 +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 EFADD13C43E; Thu, 11 Jan 2007 06:37:27 +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 1H4tYu-0005Kz-Hm; Thu, 11 Jan 2007 09:37:20 +0300 Date: Thu, 11 Jan 2007 09:37:15 +0300 From: Eygene Ryabinkin To: "Bruce M. Simpson" Message-ID: <20070111063715.GL14822@codelabs.ru> References: <459D4D88.2030708@delphij.net> <459FEDBC.4070008@FreeBSD.org> <20070107115158.GA63854@codelabs.ru> <45A54119.20809@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <45A54119.20809@FreeBSD.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.5 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-net@freebsd.org, Tadaaki Nagao , andre@freebsd.org, LI Xin 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: Thu, 11 Jan 2007 06:37:28 -0000 Bruce, good day! > >I think that this confirms my findings. Have you tried to look at your packet > >with tcpdump? Link-level MAC should be set to your routers one, not to yhe > >0xffffffff. > > > I saw this as well. The behaviour is actually as expected. FreeBSD has done > this for years. Some years ago I did some work on a fix for this, but it was > not net-smp safe. > > Wes Peters suggested treating INADDR_BROADCAST traffic like multicast-routed > traffic. Whilst the MROUTING code has queues for each entry in the Multicast > Forwarding Cache (MFC) and knows how to dispatch the same mbuf chain more than > once, it isn't compiled in by default. Fine. I will have a look at that code, may be it can be adopted to our case. But RFC 919 is a bit unclear about the case of multiple-interface hosts and INADDR_BROADCAST (from section 7): "The address 255.255.255.255 denotes a broadcast on a local hardware network, which must not be forwarded.". The current implementation correctly sets TTL = 1 for IP_ONESBCAST (as inspired by PR/99558), but it uses just one interface that is specified via its broadcast address. If we're taking "local hardware network" to be the specific interface that is to be chosen via socket options, then FreeBSD stack is behaving correctly. Then, probably, the ip(4) should be modified to document this behaviour and why it's not agains RFCs. And a patch for 'ping' should be applied to handle INADDR_BROADCAST in the specific manner. In principle, one can assume that packets for INADDR_BROADCAST should go into all local interfaces. I was able to test only at Linux (2.4): it forwards packets from 'ping -b 255.255.255.255' to the first interface with broadcast, but the interface can be chosen with '-I' option. Do you (or anyone else reading this post) have access to the different IP stack realisations at hosts with multiple broadcast-able interfaces? If yes, wouldn't you all be so kind to try to ping the broadcast address and report the behaviour? Or may be there are some arguments from RFCs, best practices or common sense on how INADDR_BROADCAST should be handled in the multiple-interfaces case? Thanks! -- Eygene