RTF_BROADCAST

[Roy Marples]

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.

Roy

[Matt Thomas]

Post by Roy Marples
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?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Matt Thomas

Post by Roy Marples
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.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de