Re: RTF_BROADCAST

[Matt Thomas <matt%3am-software.com@localhost>]

> On Mar 19, 2015, at 1:29 PM, Roy Marples <roy%marples.name@localhost> wrote:
> 
> Hi
> 
> FreeBSD added RTF_BROADCAST a very long time ago.
> I'd like to add it to NetBSD to make it clear what the route is for and
> to avoid a potentially expensive call to in_broadcast() in ip_output().
> It also avoids a needless allocation for the storage of llinfo_arp and
> thus vanishes from the output of arp(8) - it always showed as incomplete
> so this is a nice side effect.
> 
> FreeBSD also uses RTF_BROADCAST as a check to drop packets in
> ip_fastforward() .... the closest match I can find is our
> ipflow_fastforward() where I made a similar change and ensuring the
> route is not RTF_BLACKHOLE either.
> Oddly FreeBSD does not have the same functionality for IPv6 as I can
> find, but we do so I added a check there as well.
> If you are wondering why there is not a check for RTF_BROADCAST in
> ip6_fastforward() it's because broadcast addresses are a IPv4 only concept.
> 
> I've been running this patch on a few machines, including my router, for
> a few days now without any adverse effects.
> Commentary welcome.

So is the RTF_BROADCAST route permanent or just marked that way by ARP
on the fly?