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

[Bruce Simpson]

On 20/08/16 19:57, Ryan Stone wrote:
>
>
> On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov <slw at zxy.spb.ru
> <mailto:slw at 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()?