netdev - kernel never returns rtm_protocol of RTPROT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <D67825C5985D0647BE40A5F5B0B70D110D404A3AB5@HQ-EXCH-7.corp.brocade.com>
Date:	Tue, 13 Apr 2010 19:04:54 -0700
From:	Jeff Haran <jharan@...cade.COM>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: kernel never returns rtm_protocol of RTPROT_RA?

Hi,

Perhaps I am misreading the kernel sources, but it looks to me like an IPv6 default gateway that is discovered via the receipt of the Router Advertisement will not be reported in a netlink RTM_NEWROUTE message with the rtm_protocol field == RTPROT_RA, though that seems to be the defined purpose for RTPROT_RA. It seems like such addresses are going to be reported with rtm_protocol == RTPROT_KERNEL.

This is what I observe reading the sources to our old kernel (2.6.14) and actually running the data through it, and later sources seem to be doing the same thing though I haven't studied them as closely.

Is this the expected behavior?

Does anybody see any problems if I change rt6_fill_node() to put RTPROT_RA into rtm_protocol when rt6i_flags has both the RTF_ADDRCONF and RTF_DEFAULT bits set?

I am writing an application that distinguishes different sources of IPv6 routes and would like be able to count on RTPROT_RA meaning the default router address originated from a Router Advertisements.

Please include my email address in response as I do not subscribe to this list.

Thanks,

Jeff Haran
Brocade

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html