[PATCH] fix RTPROT_RA markup of some RA routes in netlink

* [PATCH] fix RTPROT_RA markup of some RA routes in netlink
@ 2012-07-09  7:37 Denis Ovsienko
  2012-07-09 21:40 ` David Miller
  0 siblings, 1 reply; 4+ messages in thread
From: Denis Ovsienko @ 2012-07-09  7:37 UTC (permalink / raw)
  To: netdev

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

Hello, list.

This is a small patch I have produced after thoroughly studying the coupling between addrconf and FIB6 functions. I believe this change to improve the transparency of FIB6 as viewed from userspace (by iproute2 in particular). It does resolve an issue I was debugging, where a default route derived from a router advertisement couldn't be told from kernel routes derived from other sources. The difference is meaningful at least for dynamic routing purposes, but other good uses are also possible.

Thank you.

-- 
    Denis Ovsienko

[-- Attachment #2: 0001-fix-RTPROT_RA-markup-of-some-RA-routes-in-netlink.patch --]
[-- Type: text/plain, Size: 2241 bytes --]

From 1d969903c6221980360f76abb5e063300e5cf3bb Mon Sep 17 00:00:00 2001
From: Denis Ovsienko <infrastation@yandex.ru>
Date: Fri, 6 Jul 2012 18:08:18 +0400
Subject: [PATCH] fix RTPROT_RA markup of some RA routes in netlink

There are three types of IPv6 routes originated by kernel ND RA code:

* Default routes standing for RA packets with non-zero router lifetime.
* Connected prefix routes standing for a Prefix Information (3) RA TLV.
* Any prefix routes standing for a Route Information (24) RA TLV.

All three types are internally stored using RTPROT_KERNEL or RTPROT_BOOT
protocol code and RTF_ADDRCONF route flag (this is the only purpose for
this flag). The flag isn't directly available in netlink socket space.
Given the need to tell route origin in userspace, for routes with
nexthops in the first turn, rt6_fill_node() tries to distinguish default
router case sending the netlink route structure with RTPROT_RA (this is
respectively the only use case for this protocol code), but to no
success due to a test condition taken wrong. All three types are
delivered with RTPROT_KERNEL.

This change is modelled after the original mailing list posting by Jeff
Haran. It fixes the test condition for the default router case and
extends it for the Route Information case.
---
 net/ipv6/route.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 999a982..2f070d6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2441,9 +2441,15 @@ static int rt6_fill_node(struct net *net,
 	if (rt->rt6i_flags & RTF_DYNAMIC)
 		rtm->rtm_protocol = RTPROT_REDIRECT;
 	else if (rt->rt6i_flags & RTF_ADDRCONF)
-		rtm->rtm_protocol = RTPROT_KERNEL;
-	else if (rt->rt6i_flags & RTF_DEFAULT)
-		rtm->rtm_protocol = RTPROT_RA;
+	{
+		/* any ND RA route, most probably originated by kernel */
+		if (rt->rt6i_flags & RTF_DEFAULT) /* default router */
+			rtm->rtm_protocol = RTPROT_RA;
+		else if (rt->rt6i_flags & RTF_ROUTEINFO) /* any route w/nexthop */
+			rtm->rtm_protocol = RTPROT_RA;
+		else /* RTF_PREFIX_RT, interface connected prefix route */
+			rtm->rtm_protocol = RTPROT_KERNEL;
+	}
 
 	if (rt->rt6i_flags & RTF_CACHE)
 		rtm->rtm_flags |= RTM_F_CLONED;
-- 
1.7.7.6


^ permalink raw reply related	[flat|nested] 4+ messages in thread