> Well, I think the problem is to set RTF_ADDRCONF flag to all prefix routes.
I don't think we should change that, RTF_ADDRCONF should be set for all RA routes not just the prefix route. But I agree with your other comments, that RTF_ADDRCONF must not be used when configuring routes from user space. The filtering should check for both the flag as well as whether it is a prefix route entry.
I guess I will work on sending messages for both prefix list changes and to get entire prefix list.
thanks,
- KK
YOSHIFUJI Hideaki wrote:
In article <3EEF7E09.8080608@us.ibm.com> (at Tue, 17 Jun 2003 13:46:01 -0700), Krishna Kumar <krkumar@us.ibm.com> says:
I have a question about the following, which seems to be the approach both of you prefer. I thought we need a new routing message type called RTM_GETPLIST which will return full prefix list. If you use RTA_RA6INFO, then should that trigger only when the prefix list has changed (add or delete) ? Should I have both interfaces, one for returning entire list (RTM) and one for changes in prefix list (RTA) ?
Please let me know if my understanding is correct.
Well, I think the problem is to set RTF_ADDRCONF flag to all prefix routes.
I beleive this should be for autoconf (RA) routes only as comments says;
dad_starts and multicast add routes with such flag, but this should be wrong.
After we fix this, we can get prefix information filtering routes by RTF_ADDRCONF flag; of course, we can get the routes using RTM_GETROUTE.
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
