[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-net
Subject:    Re: =?UTF-8?Q?RTF=5FBROADCAST?=
From:       Roy Marples <roy () marples ! name>
Date:       2015-03-20 1:48:50
Message-ID: 576fc8a78959b71980f8e778319cb701 () mail ! marples ! name
[Download RAW message or body]

On 2015-03-20 00:58, Matt Thomas wrote:
>> On Mar 19, 2015, at 1:29 PM, Roy Marples <roy@marples.name> 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?

Marked by ARP on the fly.
[prev in list] [next in list] [prev in thread] [next in thread]