RTF_LOCAL support

[Roy Marples]

Hi List

FreeBSD and OpenBSD have added the routing flag RTF_LOCAL to indicate
the route represents a local address. They also create a local route for
each IPv4 address in a similar way to IPv6. dhcpcd and dhclient-script
do this for NetBSD as well, but it makes sense to move this into the
kernel for statically added addresses as well.

I have created a patch to do this for NetBSD which also moves the bulk
of the in6_if{add,rem}loop() functions into more generic
rt_ifa_{add,rem}local() functions and also renamed to
in6_if{add,rem}local(). in_if{add,rem}local() functions have also been
added to achieve the same functionality for IPv4.

One question though - sys/netinet/ip_carp.c has a large block of code
which looks like it handles this for IPv4. the IPv6 segment just calls
in6_{add,rem}loop(). Can this large block of code be changed to call
in_if{add,rem}local() for IPv4 or have I missed something? I don't know
anything about carp(4), hence asking.

Thanks
Roy

[Christos Zoulas]

In article <***@marples.name>,
Roy Marples <***@marples.name> wrote:

Bikeshed comment warning...

Index: sys/net/route.h
===================================================================
RCS file: /cvsroot/src/sys/net/route.h,v
retrieving revision 1.84
diff -u -p -r1.84 route.h
--- sys/net/route.h 6 Jun 2014 01:02:47 -0000 1.84
+++ sys/net/route.h 24 Feb 2015 14:00:10 -0000
@@ -155,7 +155,7 @@ struct ortentry {
#define RTF_PROTO1 0x8000 /* protocol specific routing flag */
#define RTF_SRC 0x10000 /* route has fixed source address */
#define RTF_ANNOUNCE 0x20000 /* announce new arp or ndp entry */
-
+#define RTF_LOCAL 0x200000 /* route represents a local address */

Why 0x200000 instead of 0x40000?

@@ -292,22 +292,23 @@ struct rt_metrics {
.Pp
.Bd -literal
-#define RTF_UP 0x1 /* route usable */
-#define RTF_GATEWAY 0x2 /* destination is a gateway */
-#define RTF_HOST 0x4 /* host entry (net otherwise) */
-#define RTF_REJECT 0x8 /* host or net unreachable */
-#define RTF_DYNAMIC 0x10 /* created dynamically (by redirect) */
-#define RTF_MODIFIED 0x20 /* modified dynamically (by redirect) */
-#define RTF_DONE 0x40 /* message confirmed */
-#define RTF_MASK 0x80 /* subnet mask present */
-#define RTF_CLONING 0x100 /* generate new routes on use */
-#define RTF_XRESOLVE 0x200 /* external daemon resolves name */
-#define RTF_LLINFO 0x400 /* generated by ARP or ESIS */
-#define RTF_STATIC 0x800 /* manually added */
-#define RTF_BLACKHOLE 0x1000 /* just discard pkts (during updates) */
-#define RTF_CLONED 0x2000 /* this is a cloned route */
-#define RTF_PROTO2 0x4000 /* protocol specific routing flag */
-#define RTF_PROTO1 0x8000 /* protocol specific routing flag */
+#define RTF_UP 0x1 /* route usable */
+#define RTF_GATEWAY 0x2 /* destination is a gateway */
+#define RTF_HOST 0x4 /* host entry (net otherwise) */
+#define RTF_REJECT 0x8 /* host or net unreachable */
+#define RTF_DYNAMIC 0x10 /* created dynamically (by redirect) */
+#define RTF_MODIFIED 0x20 /* modified dynamically (by redirect) */
+#define RTF_DONE 0x40 /* message confirmed */
+#define RTF_MASK 0x80 /* subnet mask present */
+#define RTF_CLONING 0x100 /* generate new routes on use */
+#define RTF_XRESOLVE 0x200 /* external daemon resolves name */
+#define RTF_LLINFO 0x400 /* generated by ARP or ESIS */
+#define RTF_STATIC 0x800 /* manually added */
+#define RTF_BLACKHOLE 0x1000 /* just discard pkts (during updates) */
+#define RTF_CLONED 0x2000 /* this is a cloned route */
+#define RTF_PROTO2 0x4000 /* protocol specific routing flag */
+#define RTF_PROTO1 0x8000 /* protocol specific routing flag */
+#define RTF_LOCAL 0x200000 /* route represents a local address */

Can you sync those with the header file?

christos


--
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 Christos Zoulas
Bikeshed comment warning...

Index: sys/net/route.h
===================================================================
RCS file: /cvsroot/src/sys/net/route.h,v
retrieving revision 1.84
diff -u -p -r1.84 route.h
--- sys/net/route.h 6 Jun 2014 01:02:47 -0000 1.84
+++ sys/net/route.h 24 Feb 2015 14:00:10 -0000
@@ -155,7 +155,7 @@ struct ortentry {
#define RTF_PROTO1 0x8000 /* protocol specific routing flag */
#define RTF_SRC 0x10000 /* route has fixed source address */
#define RTF_ANNOUNCE 0x20000 /* announce new arp or ndp entry */
-
+#define RTF_LOCAL 0x200000 /* route represents a local address */

Why 0x200000 instead of 0x40000?

It's the same value used by the other OSes, no other reason.
I note that where each has the same flag, the value is also the same,
hence keeping it the same here.

Post by Christos Zoulas

@@ -292,22 +292,23 @@ struct rt_metrics {
.Pp
.Bd -literal
-#define RTF_UP 0x1 /* route usable */
-#define RTF_GATEWAY 0x2 /* destination is a gateway */
-#define RTF_HOST 0x4 /* host entry (net otherwise) */
-#define RTF_REJECT 0x8 /* host or net unreachable */
-#define RTF_DYNAMIC 0x10 /* created dynamically (by redirect) */
-#define RTF_MODIFIED 0x20 /* modified dynamically (by redirect) */
-#define RTF_DONE 0x40 /* message confirmed */
-#define RTF_MASK 0x80 /* subnet mask present */
-#define RTF_CLONING 0x100 /* generate new routes on use */
-#define RTF_XRESOLVE 0x200 /* external daemon resolves name */
-#define RTF_LLINFO 0x400 /* generated by ARP or ESIS */
-#define RTF_STATIC 0x800 /* manually added */
-#define RTF_BLACKHOLE 0x1000 /* just discard pkts (during updates) */
-#define RTF_CLONED 0x2000 /* this is a cloned route */
-#define RTF_PROTO2 0x4000 /* protocol specific routing flag */
-#define RTF_PROTO1 0x8000 /* protocol specific routing flag */
+#define RTF_UP 0x1 /* route usable */
+#define RTF_GATEWAY 0x2 /* destination is a gateway */
+#define RTF_HOST 0x4 /* host entry (net otherwise) */
+#define RTF_REJECT 0x8 /* host or net unreachable */
+#define RTF_DYNAMIC 0x10 /* created dynamically (by redirect) */
+#define RTF_MODIFIED 0x20 /* modified dynamically (by redirect) */
+#define RTF_DONE 0x40 /* message confirmed */
+#define RTF_MASK 0x80 /* subnet mask present */
+#define RTF_CLONING 0x100 /* generate new routes on use */
+#define RTF_XRESOLVE 0x200 /* external daemon resolves name */
+#define RTF_LLINFO 0x400 /* generated by ARP or ESIS */
+#define RTF_STATIC 0x800 /* manually added */
+#define RTF_BLACKHOLE 0x1000 /* just discard pkts (during updates) */
+#define RTF_CLONED 0x2000 /* this is a cloned route */
+#define RTF_PROTO2 0x4000 /* protocol specific routing flag */
+#define RTF_PROTO1 0x8000 /* protocol specific routing flag */
+#define RTF_LOCAL 0x200000 /* route represents a local address */

Can you sync those with the header file?

Sure

Roy

--
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 Roy Marples
I have created a patch to do this for NetBSD which also moves the bulk
of the in6_if{add,rem}loop() functions into more generic
rt_ifa_{add,rem}local() functions and also renamed to
in6_if{add,rem}local(). in_if{add,rem}local() functions have also been
added to achieve the same functionality for IPv4.

I have made more changes to the patch, based on today's sources.
* rtinit() now only announces network route changes, not the address
* rt_ifa_{add,rem}local() will always announce the address change
even if there is no corresponding local route change

Due to the above changes, some comments regarding potential secondary
reports for new addresses have been removed as this is no longer the case.

On 24/02/2015 19:09, Christos Zoulas wrote:> On Feb 24, 6:40pm,

Post by Roy Marples
| It's the same value used by the other OSes, no other reason.
| I note that where each has the same flag, the value is also the same,
| hence keeping it the same here.
I don't think that making the values the same matters (unless we
consider binary emulation), so I'd rather allocate the next one

sequentially.

Post by Roy Marples
What do others think?

We're talking about the value of RTF_LOCAL in route.h
Anyone else have an opinion on this before it goes into the tree?
Maybe add some comment in route.h to state the rationale?

Thanks

Roy

[Martin Husemann]

Post by Roy Marples
We're talking about the value of RTF_LOCAL in route.h

As Christos said: the numeric value does not matter anywhere, so just
use the next logical one, no matter what others do.

Martin


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

[Thor Lancelot Simon]

Post by Roy Marples
We're talking about the value of RTF_LOCAL in route.h
Anyone else have an opinion on this before it goes into the tree?

I think if there's any chance we might ever pick up the other flags
that must be in between our allocated values and this one in the other
BSDs, it makes some sense to leave space for them. What are they?

Thor

--
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 Thor Lancelot Simon

Post by Roy Marples
We're talking about the value of RTF_LOCAL in route.h
Anyone else have an opinion on this before it goes into the tree?

I think if there's any chance we might ever pick up the other flags
that must be in between our allocated values and this one in the other
BSDs, it makes some sense to leave space for them. What are they?

In don't think any other flags *have* to be between others if we pickup
their functionality.

Roy


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