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

[Bruce Simpson]

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.)