Date: Sat, 5 Aug 2006 13:51:12 +0200 From: Benjamin Lutz <benlutz@datacomm.ch> To: Mohacsi Janos <mohacsi@niif.hu> Cc: freebsd-hackers@freebsd.org Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255) Message-ID: <200608051351.16071.benlutz@datacomm.ch> In-Reply-To: <20060805071620.D83852@mignon.ki.iif.hu> References: <200608041712.11939.benlutz@datacomm.ch> <20060805071620.D83852@mignon.ki.iif.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608051351.16071.benlutz>