svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

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.