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
Please read Documentation/SubmittingPatches to learn how to submit
a proper patch with proper commit log message and a proper signoff.
The commit message should exactly describe the reason for your change
and how the change is implemented. It should not contain things like
"Hello" or "This is a patch" or "Thank you" or other irrelevant
verbiage that does not belong in the commit log message.
Thank you.
From: Denis Ovsienko <redacted>
Userspace implementations of network routing protocols sometimes need to
tell RA-originated IPv6 routes from other kernel routes to make proper
routing decisions. This makes most sense for RA routes with nexthops,
namely, default routes and Route Information routes.
The intended mean of preserving RA route origin in a netlink message is
through indicating RTPROT_RA as protocol code. Function rt6_fill_node()
tried to do that for default routes, but its test condition was taken
wrong. This change is modeled after the original mailing list posting
by Jeff Haran. It fixes the test condition for default route case and
sets the same behaviour for Route Information case (both types use
nexthops). Handling of the 3rd RA route type, Prefix Information, is
left unchanged, as it stands for interface connected routes (without
nexthops).
Signed-off-by: Denis Ovsienko <redacted>
---
net/ipv6/route.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 999a982..238b1ee 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2440,10 +2440,12 @@ static int rt6_fill_node(struct net *net,
rtm->rtm_protocol = rt->rt6i_protocol;
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;
+ else if (rt->rt6i_flags & RTF_ADDRCONF) {
+ if (rt->rt6i_flags & (RTF_DEFAULT | RTF_ROUTEINFO))
+ rtm->rtm_protocol = RTPROT_RA;
+ else
+ rtm->rtm_protocol = RTPROT_KERNEL;
+ }
if (rt->rt6i_flags & RTF_CACHE)
rtm->rtm_flags |= RTM_F_CLONED;--
1.7.7.6
From: Denis Ovsienko <redacted>
Date: Tue, 10 Jul 2012 18:45:50 +0400
From: Denis Ovsienko <redacted>
Userspace implementations of network routing protocols sometimes need to
tell RA-originated IPv6 routes from other kernel routes to make proper
routing decisions. This makes most sense for RA routes with nexthops,
namely, default routes and Route Information routes.
The intended mean of preserving RA route origin in a netlink message is
through indicating RTPROT_RA as protocol code. Function rt6_fill_node()
tried to do that for default routes, but its test condition was taken
wrong. This change is modeled after the original mailing list posting
by Jeff Haran. It fixes the test condition for default route case and
sets the same behaviour for Route Information case (both types use
nexthops). Handling of the 3rd RA route type, Prefix Information, is
left unchanged, as it stands for interface connected routes (without
nexthops).
Signed-off-by: Denis Ovsienko <redacted>
Applied to net-next, thanks.