On 20/08/16 19:57, Ryan Stone wrote:
On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov <s...@zxy.spb.ru
<mailto:s...@zxy.spb.ru>> wrote:
You also can recive this on ethernet too, IMHO, in case of /32.
Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be
relaxed on this.
There is no broadcast address on a /32 network. Independent of my
change, we would not treat a packet received on a /32 network as a
broadcast here because in_broadcast() will return 0 for it.
Hmm. That is not entirely true for /32.
Even though the link layer might be Ethernet in that case, in the
traditional BSD ifnet sense, while the broadcast address slot may have
the same value (and actual location) as the peer end of a P2P (as in
generically IFF_PPP, not just pppd(8)) interface), because it's on an
Ethernet (IFF_BROADCAST) interface, the host part of the /32's value in
in the broadcast address is still valid, and will probably get mapped
that way if M_BCAST is set on outgoing traffic. (You are, after all,
going to go through ARP on Ethernet, even for a /32, so that mapping
will be triggered.)
Unless I am missing something crucial here? As far as I can tell,
arpresolve() unconditionally resolves L2 next-hop to the value of
ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by
default for Ethernet ifnets: FF:FF:FF:FF:FF:FF.
Would that not get past the M_BCAST check which replaced the call to
in_broadcast()?
_______________________________________________
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"
