Different behavior of ping'ing INADDR_BROADCAST?

Bruce M. Simpson bms at FreeBSD.org
Thu Jan 11 00:37:56 PST 2007


Eygene Ryabinkin wrote:
> 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?
>   
Windows deals with this by assigning each interface an 'interface 
metric', which is a default metric that a route is tagged with if it 
traverses a particular interface, and adding a unicast route to its FIB 
to INADDR_BROADCAST via each IFF_BROADCAST interface configured and 
running in the system.  You can see this in the output of 'route print'.

Selection of the next-hop is then done as in the same way for any other 
unicast destination with an assigned metric. The Windows FIB supports 
equal cost multipath; ours doesn't at the present time.

The Windows approach seems much cleaner, as it simply reuses the 
existing unicast FIB lookup, although it involves adding additional 
routes to the FIB; systems with hundreds of VPN interfaces would 
therefore spam the FIB with such routes if we used this approach, 
potentially causing problems similar to those which were part of the 
reason behind the removal of PRCLONING in the FreeBSD 5.x era.

Given that these routes would normally never be exchanged with any peers 
(and the FIB is not the most appropriate place for route redistribution 
anyway), it may be preferable and acceptable to put the next-hop 
selection logic for INADDR_BROADCAST into the stack itself.

I'm personally not in favour of sending a single broadcast packet to 
multiple interfaces as it has potential for denial of service, and 
doesn't seem to be consistent with the behaviour of other systems, or 
the most common use-case for undirected broadcast, which is early boot 
and/or DHCP.
Applications such as ISC DHCP work around the traditional BSD behaviour 
by using BPF to inject and receive IP broadcasts.

The MROUTING code can potentially copy mbuf chains for each interface, 
though it tries to avoid making such copies.

Regards,
BMS


More information about the freebsd-net mailing list