Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address, try 3

2007-10-08 Thread David Miller
From: Brian Haley [EMAIL PROTECTED] Date: Wed, 03 Oct 2007 10:44:17 -0400 When the ICMPv6 Target address is multicast, Linux processes the redirect instead of dropping it. The problem is in this code in ndisc_redirect_rcv(): if (ipv6_addr_equal(dest, target)) {

[IPv6] Fix ICMPv6 redirect handling with target multicast address, try 3

2007-10-03 Thread Brian Haley
When the ICMPv6 Target address is multicast, Linux processes the redirect instead of dropping it. The problem is in this code in ndisc_redirect_rcv(): if (ipv6_addr_equal(dest, target)) { on_link = 1; } else if (!(ipv6_addr_type(target) IPV6_ADDR_LINKLOCAL)) {

[IPv6] Fix ICMPv6 redirect handling with target multicast address

2007-10-02 Thread Brian Haley
When the ICMPv6 Target address is multicast, Linux processes the redirect instead of dropping it. The problem is in this code in ndisc_redirect_rcv(): if (ipv6_addr_equal(dest, target)) { on_link = 1; } else if (!(ipv6_addr_type(target) IPV6_ADDR_LINKLOCAL)) {

Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address

2007-10-02 Thread David Stevens
Brian, ipv6_addr_type() returns a mask, so checking for equality will fail to match if any other (irrelevant) attributes are set. How about using bitwise operators for that? Also, the error message is no longer descriptive of the failure if it's a link-local multicast, but you could

Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address

2007-10-02 Thread Brian Haley
Hi David, David Stevens wrote: ipv6_addr_type() returns a mask, so checking for equality will fail to match if any other (irrelevant) attributes are set. How about using bitwise operators for that? ipv6_addr_type() does return a mask, but there's a lot of code that just checks for

Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address

2007-10-02 Thread David Stevens
Brian, I don't think a few instructions is a performance issue in the redirect paths (it'd be pretty broken if you're getting or generating lots of them), but I know there are lots of other checks similar to that that will break with new attributes, so doing that as a general clean-up

Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address

2007-10-01 Thread YOSHIFUJI Hideaki / 吉藤英明
Hello. In article [EMAIL PROTECTED] (at Sat, 29 Sep 2007 10:04:48 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] says: In article [EMAIL PROTECTED] (at Fri, 28 Sep 2007 17:50:38 -0700), David Stevens [EMAIL PROTECTED] says: Brian, A multicast address should never be

Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address

2007-10-01 Thread Brian Haley
Hi, YOSHIFUJI Hideaki / 吉藤英明 wrote: I think it'd also be better if you add the check to be: if (ipv6_addr_type(target) (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST)) or something along those lines, rather than reproducing ipv6_addr_type() code separately in a new

[IPV6] Fix ICMPv6 redirect handling with target multicast address

2007-09-28 Thread Brian Haley
When the ICMPv6 Target address is multicast, Linux processes the redirect instead of dropping it. The problem is in this code in ndisc_redirect_rcv(): if (ipv6_addr_equal(dest, target)) { on_link = 1; } else if (!(ipv6_addr_type(target) IPV6_ADDR_LINKLOCAL)) {

Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address

2007-09-28 Thread David Stevens
Brian, A multicast address should never be the target of a neighbor discovery request; the sender should use the mapping function for all multicasts. So, I'm not sure that your example can ever happen, and it certainly is ok to send ICMPv6 errors to multicast addresses in general. But I

Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address

2007-09-28 Thread YOSHIFUJI Hideaki / 吉藤英明
Dave, Brian, Let me double check this patch. Regards, --yoshfuji In article [EMAIL PROTECTED] (at Fri, 28 Sep 2007 17:50:38 -0700), David Stevens [EMAIL PROTECTED] says: Brian, A multicast address should never be the target of a neighbor discovery request; the sender should use