Date: Sat, 20 Aug 2016 16:01:40 +0100 From: Bruce Simpson <bms@fastmail.net> To: Ryan Stone <rysto32@gmail.com> Cc: Ryan Stone <rstone@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r304436 - in head: . sys/netinet Message-ID: <fcb33eac-ec99-03c7-57b5-f24f86c4f41a@fastmail.net> In-Reply-To: <CAFMmRNyi=PwE9pc9_8wCU63=HttUzFR4Zh2v=uHKcQ-zaLxdJQ@mail.gmail.com> References: <201608182259.u7IMx5oW002018@repo.freebsd.org> <4fbc2e1d-3a62-5963-83d5-f9c931503e51@fastmail.net> <3806700d-ed27-7915-4818-c2d64f7b806d@fastmail.net> <CAFMmRNyi=PwE9pc9_8wCU63=HttUzFR4Zh2v=uHKcQ-zaLxdJQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20/08/16 15:52, Ryan Stone wrote: > 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. > > Can you give an example of a tunneling protocol support by FreeBSD that > may be affected? I looked and didn't see any. OpenVPN, as best that I > can tell, injects frames into a tap interface, which appears as a > Ethernet interface, for example. Potentially any and all PPP, tun(4); any link layer with plain IP on top of it other than Ethernet, which may not set M_BCAST for an IPv4 broadcast packet (or does not distinguish between broadcast and unicast/multicast packets). if_ethersubr.c does set M_BCAST correctly for Ethernet broadcast packets in the receive path. That is guaranteed, and the majority of Ethernet network drivers will pass packets up the stack through it more or less directly. tap(4) is an exception because, as you rightly point out, it is pretty faithfully Ethernet, although I may have had to add code around Ethernet address conditions like this to it in the very distant past. tun(4) on the other hand is a plain, PPP-like, IP tunnel. But this mbuf flag is not guaranteed to be set in all situations; e.g. where the link layer does not have the concept of broadcast being distinct from other kinds of network traffic. PPP and ATM are the most obvious examples.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fcb33eac-ec99-03c7-57b5-f24f86c4f41a>