Different behavior of ping'ing INADDR_BROADCAST?

[Eygene Ryabinkin]

Bruce, good day!

> >I think that this confirms my findings. Have you tried to look at your packet
> >with tcpdump? Link-level MAC should be set to your routers one, not to yhe
> >0xffffffff.
> >  
> I saw this as well. The behaviour is actually as expected. FreeBSD has done 
> this for years. Some years ago I did some work on a fix for this, but it was 
> not net-smp safe.
> 
> Wes Peters suggested treating INADDR_BROADCAST traffic like multicast-routed 
> traffic. Whilst the MROUTING code has queues for each entry in the Multicast 
> Forwarding Cache (MFC) and knows how to dispatch the same mbuf chain more than
> once, it isn't compiled in by default.

Fine. I will have a look at that code, may be it can be adopted to
our case.

But RFC 919 is a bit unclear about the case of multiple-interface hosts
and INADDR_BROADCAST (from section 7): "The address 255.255.255.255
denotes a broadcast on a local hardware network, which must not be
forwarded.". The current implementation correctly sets TTL = 1
for IP_ONESBCAST (as inspired by PR/99558), but it uses just one
interface that is specified via its broadcast address. If we're
taking "local hardware network" to be the specific interface that is to be
chosen via socket options, then FreeBSD stack is behaving correctly.
Then, probably, the ip(4) should be modified to document this behaviour
and why it's not agains RFCs. And a patch for 'ping' should be applied
to handle INADDR_BROADCAST in the specific manner.

In principle, one can assume that packets for INADDR_BROADCAST should
go into all local interfaces. I was able to test only at Linux (2.4):
it forwards packets from 'ping -b 255.255.255.255' to the first interface
with broadcast, but the interface can be chosen with '-I' option.
Do you (or anyone else reading this post) have access to the different
IP stack realisations at hosts with multiple broadcast-able interfaces?
If yes, wouldn't you all be so kind to try to ping the broadcast address
and report the behaviour?

Or may be there are some arguments from RFCs, best practices or common
sense on how INADDR_BROADCAST should be handled in the multiple-interfaces
case?

Thanks!
-- 
Eygene