From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 5 11:51:30 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 652C616A4DA for ; Sat, 5 Aug 2006 11:51:30 +0000 (UTC) (envelope-from benlutz@datacomm.ch) Received: from popeye1.ggamaur.net (popeye1.ggamaur.net [213.160.40.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7167D43D53 for ; Sat, 5 Aug 2006 11:51:29 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by popeye1.ggamaur.net (8.13.7/8.13.7/Submit) with ESMTP id k75BpOxZ025215; Sat, 5 Aug 2006 13:51:26 +0200 (CEST) (envelope-from benlutz@datacomm.ch) Received: from localhost (unknown [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 903F82E10A; Sat, 5 Aug 2006 13:51:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at atlantis.intranet Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (atlantis.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFoHekmwUFgu; Sat, 5 Aug 2006 13:51:19 +0200 (CEST) Received: from mini.intranet (mini.intranet [10.0.0.17]) by maxlor.mine.nu (Postfix) with ESMTP id 530D52E0CE; Sat, 5 Aug 2006 13:51:19 +0200 (CEST) From: Benjamin Lutz To: Mohacsi Janos Date: Sat, 5 Aug 2006 13:51:12 +0200 User-Agent: KMail/1.9.1 References: <200608041712.11939.benlutz@datacomm.ch> <20060805071620.D83852@mignon.ki.iif.hu> In-Reply-To: <20060805071620.D83852@mignon.ki.iif.hu> X-Face: $Ov27?7*N,h60fIEfNJdb!m,@#4T/d; 1hw|W0zvsHM(a$Yn6BYQ0^SEEXvi8>D`|V*F"=?iso-8859-1?q?=5F+R=0A?= 2@Aq>+mNb4`,'[[%z9v0Fa~]AD1}xQO3|>b.z&}l#R-_(P`?@Mz"kS; XC>Eti,i3>%@g?4f,=?iso-8859-1?q?=5Cc7=7CGh=0A?= =?iso-8859-1?q?_wb=26ky=24b2PJ=5E=5C0b83NkLsFKv=7CsmL/cI4UD=25Tu8alAD?= MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1559819.93zyx9al9W"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200608051351.16071.benlutz@datacomm.ch> X-Scanned-By: MIMEDefang 2.57 on 213.160.40.60 Cc: freebsd-hackers@freebsd.org Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 11:51:30 -0000 --nextPart1559819.93zyx9al9W Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 05 August 2006 07:18, you wrote: > On Fri, 4 Aug 2006, Benjamin Lutz wrote: > > Hello, > > > > I've noticed that FreeBSD does not by default comply to RFC 919, Chapter > > 7 (http://tools.ietf.org/html/rfc919). Specifically, it does not handle > > IP packets with a destination address of 255.255.255.255 properly. > > > > 255.255.255.255 is a "limited broadcast address" (the term is not > > mentioned in the RFC, but seems to be in use everywhere else). An IP > > packet send to that address should be broadcast to the whole IP subnet = of > > the broadcasting device. However, in FreeBSD (4.11, 5.5, 6.1) this does > > not work, as is evident by this tcpdump output: > > > > 17:00:59.125132 00:12:17:5a:b3:b6 > 00:40:63:d9:a9:28, ethertype IPv4 > > (0x0800), length 98: 10.0.0.1 > 255.255.255.255: ICMP echo request, id > > 33319, seq 0, length 64 > > > > The destination MAC address is that of my gateway, but it should be > > ff:ff:ff:ff:ff:ff. You can reproduce this by running "tcpdump -en ip > > proto 1" and "ping 255.255.255.255". > > > > I found a discussion from 2003 about this, but it seems to have trailed > > off without coming to a conclusion: > > http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html > > > > I've noticed that the ip(7) manpage lists a SO_ONESBCAST option. The > > intention seems to be to enable packets to 255.255.255.255. However a > > test with a small program showed that this option seems to have no > > effect, outgoing packets still carried the gateway's MAC address as > > destination. > > > > Btw, Linux and NetBSD both handle packets to 255.255.255.255 as > > broadcasts. > > > > Now, is this behaviour intentional? Is there a way to turn on RFC 919 > > compliance? If not, would someone be willing to add this to the kernel? > > Should I submit a PR? > > Does this feature really necessary? For waht purpose? I discovered it when playing with Wake-on-LAN packets. It is possible to se= nd=20 those with the real subnet's broadcast address, but then you first have to= =20 figure that one out. If you have a network device that doesn't have an IP=20 configured yet, it would not know the subnet broadcast address. > I believe this feature is more harmful than useful. Please elaborate. Remember that routers do not pass on packets to=20 255.255.255.255. The TTL is effectively 1. Cheers Benjamin --nextPart1559819.93zyx9al9W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBE1IY0gShs4qbRdeQRAgDFAJwIhjG/sqbgmTTxmNhKsyG5C2OCYQCfWyZ2 +K0xBHAMsZgnQNM9F0r3lo4= =wIRG -----END PGP SIGNATURE----- --nextPart1559819.93zyx9al9W--