On 20/08/16 21:05, Bruce Simpson wrote:
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()?
Based on my reading of the UDP-and-plumbing layer, it looks like we will
only see FF:FF:FF:FF:FF:FF being used by the undirected IPv4 broadcast
address, 255.255.255.255.
But, in fact, this is probably a far more valid address to use for
discovery services than the x.x.x.255-style IPv4 directed broadcast
address, as, for Ethernet at least, it is guaranteed not to propagate
beyond 1 union-of (on-link broadcast domain (layer 2, hop 1) & other
ways that IPv4 subnet is bridged).
So, Ryan -- your original reading of how in_broadcast() behaves is
correct, modulo the all-ones bypassing it.
(I believe dhclient and isc-dhcpd bypass it at BPF injection, though.)
_______________________________________________
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"
