Date: Sat, 20 Aug 2016 12:48:00 +0100 From: Bruce Simpson <bms@fastmail.net> To: Ryan Stone <rstone@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r304436 - in head: . sys/netinet Message-ID: <3806700d-ed27-7915-4818-c2d64f7b806d@fastmail.net> In-Reply-To: <4fbc2e1d-3a62-5963-83d5-f9c931503e51@fastmail.net> References: <201608182259.u7IMx5oW002018@repo.freebsd.org> <4fbc2e1d-3a62-5963-83d5-f9c931503e51@fastmail.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20/08/16 12:33, Bruce Simpson wrote: > This potentially breaks reception of IPv4 broadcasts where FreeBSD is > the endpoint at the end of a P2P interface, or other forms of links, > where there is no guarantee that the link layer will set M_BCAST (or > indeed M_MCAST). I appreciate it probably looks like a quick win, but if it's only been tested with Ethernet (it looks like it has only been written with Ethernet in mind), it does strongly look as if it breaks broadcast for UDP/IPv4 in other situations. So, maybe it should be backed out ASAP. (I haven't tested this code.) It is perfectly legal for broadcast packets to be addressed to the end of a P2P or non-Ethernet link, which may not set M_BCAST or M_MCAST. The classic example is ATM (Non-Broadcast, Multiple Access (NBMA)) but the situation may be readily observed with loopback or tunnels. The same issue doesn't exist in your output path change, which looks sane. The same issue doesn't exist with IPv6 where broadcast is dead.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3806700d-ed27-7915-4818-c2d64f7b806d>