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.
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
