In article [EMAIL PROTECTED] (at Wed, 21 Feb 2007 00:02:22 -0800 (PST)),
David Miller [EMAIL PROTECTED] says:
So, I think it is ready. Here's my sign-off:
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Neil, please keep this patch ready for the next merge window.
Dave, Neil,
I
From: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Wed, 21 Feb 2007 17:15:45 +0900 (JST)
In article [EMAIL PROTECTED] (at Wed, 21 Feb 2007 00:02:22 -0800 (PST)),
David Miller [EMAIL PROTECTED] says:
So, I think it is ready. Here's my sign-off:
Signed-off-by: YOSHIFUJI Hideaki [EMAIL
On Wed, Feb 21, 2007 at 01:30:31AM -0800, David Miller wrote:
From: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Wed, 21 Feb 2007 17:15:45 +0900 (JST)
In article [EMAIL PROTECTED] (at Wed, 21 Feb 2007 00:02:22 -0800 (PST)),
David Miller [EMAIL PROTECTED] says:
So, I think it is ready.
On Tue, Feb 13, 2007 at 08:27:59AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Thu, 8 Feb 2007 08:07:15 -0500), Neil
Horman [EMAIL PROTECTED] says:
I still have a question. Now, who will install the kernel route for
the incoming packet? Can we get packet
I still have a question. Now, who will install the kernel route for
the incoming packet? Can we get packet for our unicast address during
optimistic DAD period?
As per Yoshifjui's observation, the current patch doesn't currently allow for
the reception of inbound packets to our optimistic
In article [EMAIL PROTECTED] (at Tue, 13 Feb 2007 15:45:15 -0500), Neil
Horman [EMAIL PROTECTED] says:
Signed-off-by: Neil Horman [EMAIL PROTECTED]
I'm starting regression tests now.
--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
From: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Wed, 14 Feb 2007 06:46:49 +0900 (JST)
In article [EMAIL PROTECTED] (at Tue, 13 Feb 2007 15:45:15 -0500), Neil
Horman [EMAIL PROTECTED] says:
Signed-off-by: Neil Horman [EMAIL PROTECTED]
I'm starting regression tests now.
Thank you.
-
To
New patch attached with these fixes included
Ping? Any further thoughts here? My (allbeit limited) testing seems to be going
fairly well so far...
Neil
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
include/linux/if_addr.h |1
include/linux/ipv6.h|
In article [EMAIL PROTECTED] (at Thu, 8 Feb 2007 08:07:15 -0500), Neil Horman
[EMAIL PROTECTED] says:
I still have a question. Now, who will install the kernel route for
the incoming packet? Can we get packet for our unicast address during
optimistic DAD period?
Not sure what you're
On Thu, Feb 08, 2007 at 06:52:06AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Wed, 7 Feb 2007 15:55:03 -0500), Neil
Horman [EMAIL PROTECTED] says:
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 7b7bd44..8a1ea96 100644
---
On Thu, Feb 08, 2007 at 07:26:20AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Wed, 7 Feb 2007 15:55:03 -0500), Neil
Horman [EMAIL PROTECTED] says:
@@ -559,7 +562,7 @@ void ndisc_send_ns(struct net_device *dev, struct
neighbour *neigh,
return;
In article [EMAIL PROTECTED] (at Thu, 8 Feb 2007 11:41:52 -0500), Neil Horman
[EMAIL PROTECTED] says:
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 7b7bd44..07a5f4d 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -859,6 +859,40 @@ static int
On Fri, Feb 09, 2007 at 02:10:37AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Thu, 8 Feb 2007 11:41:52 -0500), Neil
Horman [EMAIL PROTECTED] says:
snip
These should be placed
}
here. No?
Yes, you're right. After re-reading the logic, its pretty
On Tue, Feb 06, 2007 at 04:13:25PM -0500, Vlad Yasevich wrote:
Hi Neil
a few comments. sorry, just can't resist... :)
More majordomo info at http://vger.kernel.org/majordomo-info.html
Its really ok :). Brian found some other minor typos as well. I've attached
the latest patch which takes
Darn... and it was looking so good...
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 7b7bd44..8a1ea96 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -859,6 +859,34 @@ static int ip6_dst_lookup_tail(struct sock *sk,
err =
In article [EMAIL PROTECTED] (at Wed, 7 Feb 2007 15:55:03 -0500), Neil Horman
[EMAIL PROTECTED] says:
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 7b7bd44..8a1ea96 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -859,6 +859,34 @@ static int
In article [EMAIL PROTECTED] (at Wed, 7 Feb 2007 15:55:03 -0500), Neil Horman
[EMAIL PROTECTED] says:
@@ -559,7 +562,7 @@ void ndisc_send_ns(struct net_device *dev, struct
neighbour *neigh,
return;
len = sizeof(struct icmp6hdr) + sizeof(struct in6_addr);
-
On Tue, Feb 06, 2007 at 10:24:05AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
Hello.
snip
Thank you Yoshifuji. To be honest, I've been focused on functionality rather
than pretty so far, figuring I'd clean up the tabbing from my various patch
inclusions/reversions when we had agreed that the
On Tue, Feb 06, 2007 at 07:51:44AM -0500, Neil Horman wrote:
On Tue, Feb 06, 2007 at 10:24:05AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
Hello.
snip
Thank you Yoshifuji. To be honest, I've been focused on functionality rather
Ok, New patch attached, taking Vlad and Yoshifujis latest
Hi Neil
a few comments. sorry, just can't resist... :)
@@ -2627,6 +2673,9 @@ static void addrconf_dad_completed(struct inet6_ifaddr
*ifp)
* Configure the address for reception. Now it is valid.
*/
+ if (ifp-flags IFA_F_OPTIMISTIC)
+
Please, if you think you can find a way for us to do optimistic dad flags as
opt-in, rather than masked out, I'm all for it. Thanks!
This patch should apply on-top of yours, if you want I can send the
whole thing out too. I've only compile-tested it, so don't know if it
behaves the same as
Hello.
In article [EMAIL PROTECTED] (at Mon, 5 Feb 2007 15:56:51 -0500), Neil Horman
[EMAIL PROTECTED] says:
if (ifp == NULL valid_lft) {
int max_addresses = in6_dev-cnf.max_addresses;
+ u32 addr_flags = 0;
+
+#ifdef
From: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Tue, 06 Feb 2007 10:24:05 +0900 (JST)
@@ -498,7 +500,8 @@ static void ndisc_send_na(struct net_device *dev,
struct neighbour *neigh,
msg-icmph.icmp6_unused = 0;
msg-icmph.icmp6_router= router;
In article [EMAIL PROTECTED] (at Mon, 05 Feb 2007 17:32:58 -0800 (PST)),
David Miller [EMAIL PROTECTED] says:
From: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Tue, 06 Feb 2007 10:24:05 +0900 (JST)
@@ -498,7 +500,8 @@ static void ndisc_send_na(struct net_device *dev,
struct neighbour
From: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Tue, 06 Feb 2007 10:44:08 +0900 (JST)
Yes, I agree, but I think it is different issue, and
maybe, we should check and change other places as well,
in separate patch(es).
I agree.
-
To unsubscribe from this list: send the line unsubscribe netdev
On Fri, Feb 02, 2007 at 05:22:31PM -0500, Vlad Yasevich wrote:
Neil Horman wrote:
On Fri, Feb 02, 2007 at 11:46:08AM -0800, David Miller wrote:
From: Neil Horman [EMAIL PROTECTED]
Date: Fri, 2 Feb 2007 14:06:34 -0500
Ok, I'm still testing it, but heres a new patch for review.
On Fri, Feb 02, 2007 at 04:50:35PM -0500, Vlad Yasevich wrote:
Neil Horman wrote:
Ok, I'm still testing it, but heres a new patch for review. Significant
changes
include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is
dependent on
the inclusion of both IPPV6 and
On Fri, Feb 02, 2007 at 06:57:37PM -0500, Brian Haley wrote:
Hi Vlad,
Vlad Yasevich wrote:
Brian Haley wrote:
Hi Neil,
@@ -830,7 +836,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) max_addresses ?
ipv6_add_addr(idev, addr, tmp_plen,
-
Ok, I'm still testing it, but heres a new patch for review. Significant changes
include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent on
the inclusion of both IPPV6 and EXPERIMENTAL options, as well as a new method
for redirecting packets from optimistic sources to
From: Neil Horman [EMAIL PROTECTED]
Date: Fri, 2 Feb 2007 14:06:34 -0500
Ok, I'm still testing it, but heres a new patch for review.
Significant changes include the addition of a
CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent on the inclusion
of both IPPV6 and EXPERIMENTAL options, as
On Fri, Feb 02, 2007 at 11:46:08AM -0800, David Miller wrote:
From: Neil Horman [EMAIL PROTECTED]
Date: Fri, 2 Feb 2007 14:06:34 -0500
Ok, I'm still testing it, but heres a new patch for review.
Significant changes include the addition of a
CONFIG_IPV6_OPTIMISTIC_DAD option that is
Hi Neil,
@@ -830,7 +836,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) max_addresses ?
ipv6_add_addr(idev, addr, tmp_plen,
- ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK,
IFA_F_TEMPORARY) : NULL;
+
Neil Horman wrote:
Ok, I'm still testing it, but heres a new patch for review. Significant
changes
include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent
on
the inclusion of both IPPV6 and EXPERIMENTAL options, as well as a new method
for redirecting packets from
Brian Haley wrote:
Hi Neil,
@@ -830,7 +836,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) max_addresses ?
ipv6_add_addr(idev, addr, tmp_plen,
- ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK,
IFA_F_TEMPORARY) : NULL;
+
Neil Horman wrote:
On Fri, Feb 02, 2007 at 11:46:08AM -0800, David Miller wrote:
From: Neil Horman [EMAIL PROTECTED]
Date: Fri, 2 Feb 2007 14:06:34 -0500
Ok, I'm still testing it, but heres a new patch for review.
Significant changes include the addition of a
CONFIG_IPV6_OPTIMISTIC_DAD
Hi Vlad,
Vlad Yasevich wrote:
Brian Haley wrote:
Hi Neil,
@@ -830,7 +836,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) max_addresses ?
ipv6_add_addr(idev, addr, tmp_plen,
- ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK,
IFA_F_TEMPORARY)
On Wed, Jan 31, 2007 at 01:16:29AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Tue, 30 Jan 2007 08:02:08 -0500), Neil
Horman [EMAIL PROTECTED] says:
I do not think we should copy neighbor information from (one of)
default routers, but use temporary neigh
On Tue, Jan 30, 2007 at 07:25:36AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Mon, 29 Jan 2007 16:30:13 -0500), Neil
Horman [EMAIL PROTECTED] says:
Quick reality check here. In thinking about how best to go about this
redirection of frames to the default
In article [EMAIL PROTECTED] (at Tue, 30 Jan 2007 08:02:08 -0500), Neil
Horman [EMAIL PROTECTED] says:
I do not think we should copy neighbor information from (one of)
default routers, but use temporary neigh entry (or neigh in new state)
for such datagrams in stead. We should aware that:
On Fri, Jan 26, 2007 at 04:42:41PM -0500, Vlad Yasevich wrote:
Neil Horman wrote:
On Fri, Jan 26, 2007 at 03:28:40PM -0500, Vlad Yasevich wrote:
Hi Neil
Neil Horman wrote:
On Fri, Jan 26, 2007 at 09:13:31AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Thu,
Quick reality check here. In thinking about how best to go about this
redirection of frames to the default router, based on Dave M.s input, I think
that the best solution would be in ndisc_send_ns. What I was thinking was that
in ndisc_send_ns, we already detect if a source address is
In article [EMAIL PROTECTED] (at Mon, 29 Jan 2007 16:30:13 -0500), Neil
Horman [EMAIL PROTECTED] says:
Quick reality check here. In thinking about how best to go about this
redirection of frames to the default router, based on Dave M.s input, I think
that the best solution would be in
YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
Horman [EMAIL PROTECTED] says:
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2a7e461..46f91ee 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -830,7 +830,8
On Thu, Jan 25, 2007 at 05:13:57PM -0500, Vlad Yasevich wrote:
Hi Neil
I prefer to be more explicit in my order of operation, but that does seem
more
consistent with the prevaling style. New patch attached.
Looks good to me.
One question thought. What causes the stack to
In article [EMAIL PROTECTED] (at Fri, 26 Jan 2007 09:27:30 -0500), Neil
Horman [EMAIL PROTECTED] says:
I'm looking for it at the moment, but I too had assumed that redirecting the
outgoing packet to the default router would happen automatically within the
routing code as a result of not
On Sat, Jan 27, 2007 at 12:44:29AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Fri, 26 Jan 2007 09:27:30 -0500), Neil
Horman [EMAIL PROTECTED] says:
I'm looking for it at the moment, but I too had assumed that redirecting the
outgoing packet to the default
On Fri, Jan 26, 2007 at 09:13:31AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
Horman [EMAIL PROTECTED] says:
New patch attached with most of your suggestions incorporated. I've a few
comments mixed in for some of the
Hi Neil
Neil Horman wrote:
On Fri, Jan 26, 2007 at 09:13:31AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
Horman [EMAIL PROTECTED] says:
New patch attached with most of your suggestions incorporated. I've a few
comments
On Fri, Jan 26, 2007 at 03:28:40PM -0500, Vlad Yasevich wrote:
Hi Neil
Neil Horman wrote:
On Fri, Jan 26, 2007 at 09:13:31AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
Horman [EMAIL PROTECTED] says:
New patch
On Wed, Jan 24, 2007 at 05:54:47PM -0800, Sridhar Samudrala wrote:
Sec 2.1 of RFC 4429 says
Unless noted otherwise, components of the IPv6 protocol stack should
treat addresses in the Optimistic state equivalently to those in the
Deprecated state, indicating that the address is
Neil Horman wrote:
On Wed, Jan 24, 2007 at 05:54:47PM -0800, Sridhar Samudrala wrote:
Sec 2.1 of RFC 4429 says
Unless noted otherwise, components of the IPv6 protocol stack should
treat addresses in the Optimistic state equivalently to those in the
Deprecated state, indicating that
On Thu, Jan 25, 2007 at 12:16:59PM -0500, Vlad Yasevich wrote:
snip
I tend to agree with Neil here. Marking optimistic addresses as deprecated
doesn't
buy as much since the address can transition in and out of deprecated state
regardless
of DAD.
However, there is a problem with the
Hi Neil
@@ -1027,15 +1029,17 @@ int ipv6_dev_get_saddr(struct net_device *daddr_dev,
}
}
- /* Rule 3: Avoid deprecated address */
+ /* Rule 3: Avoid deprecated and optimistic address */
On Thu, Jan 25, 2007 at 03:18:59PM -0500, Vlad Yasevich wrote:
Hi Neil
@@ -1027,15 +1029,17 @@ int ipv6_dev_get_saddr(struct net_device *daddr_dev,
}
}
- /* Rule 3: Avoid deprecated address */
+ /*
Hi Neil
I went through the RFC again it seems like the following is missing:
Section 3.3:
* (modifies section 5.4.2) The host MUST join the all-nodes multicast
address and the solicited-node multicast address of the
Tentative address. The host SHOULD NOT delay before sending
In article [EMAIL PROTECTED] (at Thu, 25 Jan 2007 14:45:00 -0500), Neil
Horman [EMAIL PROTECTED] says:
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2a7e461..46f91ee 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -830,7 +830,8 @@ retry:
ift =
Sec 2.1 of RFC 4429 says
Unless noted otherwise, components of the IPv6 protocol stack should
treat addresses in the Optimistic state equivalently to those in the
Deprecated state, indicating that the address is available for use
but should not be used if another suitable address is
On Mon, Jan 22, 2007 at 03:25:39PM -0500, Vlad Yasevich wrote:
Hi Neil
snip
Yeah, I think your right. I missed the implication of testing for (!dad) at the
top of that clause. I think we could accomplish the same thing by moving my
additions to the top of the clause, but I think your logic
Hi Neil
Neil Horman wrote:
+ /*
+ * This is not a dad solicitation, meaning we
may
+ * need to respond to it, if we are
+ * an optimistic node, go ahead, otherwise
+
On Tue, Jan 23, 2007 at 09:18:20AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
Hello.
snip
New patch attached, incorporating Yoshijui and Vlads latest comments. I didn't
follow guidance on the ndisc_recv_ns comment, Yoshifuji, since Vlad had already
suggested an alternate solution in a previous
On Sat, Jan 20, 2007 at 08:05:07AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
Hello.
In article [EMAIL PROTECTED] (at Fri, 19 Jan 2007 16:23:14 -0500), Neil
Horman [EMAIL PROTECTED] says:
Patch to Implement IPv6 RFC 4429 (Optimistic Duplicate Address Detection).
In
Good work. We will
On Mon, Jan 22, 2007 at 08:39:24PM +0200, Mika Penttilä wrote:
Neil Horman wrote:
snip
I think you should remove / modify the :
if (!dad)
goto out;
which makes the rfc4429 tests not functional.
--Mika
Yeah, I think you're right. In fact, as I look at it more closely I think
Hi Neil
I don't this is still right...
@@ -746,6 +772,7 @@ static void ndisc_recv_ns(struct sk_buff *skb)
int dad = ipv6_addr_any(saddr);
int inc;
int is_router;
+ int type;
if (ipv6_addr_is_multicast(msg-target)) {
ND_PRINTK2(KERN_WARNING
@@
Hello.
In article [EMAIL PROTECTED] (at Mon, 22 Jan 2007 13:15:28 -0500), Neil
Horman [EMAIL PROTECTED] says:
Reposted patch, with your suggestions/corrections incorporated. The only
thing
I left alone was your last comment regarding the checking of saddr for being a
unicast address.
Hello.
In article [EMAIL PROTECTED] (at Fri, 19 Jan 2007 16:23:14 -0500), Neil
Horman [EMAIL PROTECTED] says:
Patch to Implement IPv6 RFC 4429 (Optimistic Duplicate Address Detection). In
Good work. We will see if this would break core and basic ipv6 code.
Dave, please hold on.
Some quick
On Sat, Jan 20, 2007 at 08:05:07AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
Hello.
In article [EMAIL PROTECTED] (at Fri, 19 Jan 2007 16:23:14 -0500), Neil
Horman [EMAIL PROTECTED] says:
Patch to Implement IPv6 RFC 4429 (Optimistic Duplicate Address Detection).
In
Good work. We will
66 matches
Mail list logo
