All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] IPv6: Change addrconf code to deal with link changes better
@ 2010-09-10 20:58 Brian Haley
  2010-09-10 22:27 ` Alexander Clouter
  0 siblings, 1 reply; 4+ messages in thread
From: Brian Haley @ 2010-09-10 20:58 UTC (permalink / raw)
  To: David Miller, YOSHIFUJI Hideaki; +Cc: netdev

I recently started noticing that sometimes I wasn't seeing all the "normal"
IPv6 packets (DAD, MLD, Router Solicit) when I was bringing-up interfaces.
I found that sometimes the link on some NICs was going up-down-up like
this:

 ADDRCONF(NETDEV_UP): eth3: link is not ready
 e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
 ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready
 (DAD queued here)
 e1000e: eth3 NIC Link is Down
 e1000e: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

This is all tcpdump showed on a remote system:

 IP6 fe80::21f:29ff:fe59:fac9 > ff02::2: ICMP6, router solicitation, length 16
 IP6 fe80::21f:29ff:fe59:fac9 > ff02::2: ICMP6, router solicitation, length 16

The addrconf code isn't written to handle this case, and won't restart DAD.
With the patch below I get this (DAD_KICK was for debugging):

 ADDRCONF(NETDEV_UP): eth6: link is not ready
 e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
 ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready
 DAD_KICK(fe80::21f:29ff:fe59:faca): eth6
 e1000e: eth6 NIC Link is Down
 ADDRCONF(NETDEV_CHANGE): eth6: link is not ready
 e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
 ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready
 DAD_KICK(fe80::21f:29ff:fe59:faca): eth6

And corresponding tcpdump:

 IP6 :: > ff02::1:ff59:faca: ICMP6, neighbor solicitation, who has fe80::21f:29ff:fe59:faca, length 24
 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
 IP6 fe80::21f:29ff:fe59:faca > ff02::2: ICMP6, router solicitation, length 16

I also noticed that sometimes during these blips that addrconf_dad_kick()
could be called twice, transmitting two DAD packets and resetting the
timer another second into the future, so I introduced a "Need DAD" state
to signify that DAD has not been started yet.  With both of these applied
the behavior is much better.

--

Change the IPv6 addrconf code to handle the case where the NIC link
state goes UP-DOWN-UP by removing all the autoconfigured addresses
when it goes down, so that when it comes back up they will get added
again and DAD will be triggered.  Also added a "Need DAD" state so that
we don't accidentally start it twice for the same address, sending a
duplicate packet and delaying when the address is available for use.

Signed-off-by: Brian Haley <brian.haley@hp.com>

diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
index f95ff8d..57432f1 100644
--- a/include/net/if_inet6.h
+++ b/include/net/if_inet6.h
@@ -33,6 +33,7 @@
 #ifdef __KERNEL__
 
 enum {
+	INET6_IFADDR_STATE_NEEDDAD,
 	INET6_IFADDR_STATE_DAD,
 	INET6_IFADDR_STATE_POSTDAD,
 	INET6_IFADDR_STATE_UP,
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 5bc893e..fabafc7 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2517,13 +2517,27 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
 			if (!idev && dev->mtu >= IPV6_MIN_MTU)
 				idev = ipv6_add_dev(dev);
 
-			if (idev) {
-				idev->if_flags |= IF_READY;
+			/*
+			 * Only start DAD if the device is ready, IF_READY
+			 * will have been set by ipv6_add_dev() if so.
+			 */
+			if (idev && idev->if_flags & IF_READY)
 				run_pending = 1;
-			}
 		} else {
 			if (!addrconf_qdisc_ok(dev)) {
-				/* device is still not ready. */
+				/*
+				 * Device is still not ready.  If we've already
+				 * configured addresses, remove them now as
+				 * we'll need to start DAD all over again.
+				 */
+				printk(KERN_INFO
+					"ADDRCONF(NETDEV_CHANGE): %s: "
+					"link is not ready\n",
+					dev->name);
+
+				if (idev && idev->if_flags & IF_READY)
+					addrconf_ifdown(dev, 0);
+
 				break;
 			}
 
@@ -2736,7 +2750,7 @@ static int addrconf_ifdown(struct net_device *dev, int how)
 
 			/* Flag it for later restoration when link comes up */
 			ifa->flags |= IFA_F_TENTATIVE;
-			ifa->state = INET6_IFADDR_STATE_DAD;
+			ifa->state = INET6_IFADDR_STATE_NEEDDAD;
 
 			write_unlock_bh(&idev->lock);
 
@@ -2847,6 +2861,7 @@ static void addrconf_dad_kick(struct inet6_ifaddr *ifp)
 		rand_num = net_random() % (idev->cnf.rtr_solicit_delay ? : 1);
 
 	ifp->probes = idev->cnf.dad_transmits;
+	ifp->state = INET6_IFADDR_STATE_DAD;
 	addrconf_mod_timer(ifp, AC_DAD, rand_num);
 }
 
@@ -2992,7 +3007,7 @@ static void addrconf_dad_run(struct inet6_dev *idev)
 	list_for_each_entry(ifp, &idev->addr_list, if_list) {
 		spin_lock(&ifp->lock);
 		if (ifp->flags & IFA_F_TENTATIVE &&
-		    ifp->state == INET6_IFADDR_STATE_DAD)
+		    ifp->state == INET6_IFADDR_STATE_NEEDDAD)
 			addrconf_dad_kick(ifp);
 		spin_unlock(&ifp->lock);
 	}

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] IPv6: Change addrconf code to deal with link changes better
  2010-09-10 20:58 [PATCH] IPv6: Change addrconf code to deal with link changes better Brian Haley
@ 2010-09-10 22:27 ` Alexander Clouter
  2010-09-11  1:10   ` Brian Haley
  0 siblings, 1 reply; 4+ messages in thread
From: Alexander Clouter @ 2010-09-10 22:27 UTC (permalink / raw)
  To: netdev

Brian Haley <brian.haley@hp.com> wrote:
> 
> [snipped]
> 
> Change the IPv6 addrconf code to handle the case where the NIC link
> state goes UP-DOWN-UP by removing all the autoconfigured addresses
> when it goes down, so that when it comes back up they will get added
> again and DAD will be triggered.  
> 
Surely this is going to result in me sending you lots of rude emails 
everytime cursing you when my SSH connections are terminated for no real 
reason on a link flap?  Privacy addresses are handy on servers too such 
as DNS servers...

When on occasion I am forced to use Windows, those darn PuTTY disconnect 
popups I see each time I disconnect/connect from our wireless network 
nearly put axe swinging mood as it is.  Please, spare me experiencing 
this pain under Linux...

Of course I could be talking nonsense, so ignore this email and keep up 
the good work :)

Cheers

-- 
Alexander Clouter
.sigmonster says: Cole's Law:
                  	Thinly sliced cabbage.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] IPv6: Change addrconf code to deal with link changes better
  2010-09-10 22:27 ` Alexander Clouter
@ 2010-09-11  1:10   ` Brian Haley
  2010-09-14  4:37     ` David Miller
  0 siblings, 1 reply; 4+ messages in thread
From: Brian Haley @ 2010-09-11  1:10 UTC (permalink / raw)
  To: Alexander Clouter; +Cc: netdev

On 09/10/2010 06:27 PM, Alexander Clouter wrote:
> Brian Haley <brian.haley@hp.com> wrote:
>>
>> [snipped]
>>
>> Change the IPv6 addrconf code to handle the case where the NIC link
>> state goes UP-DOWN-UP by removing all the autoconfigured addresses
>> when it goes down, so that when it comes back up they will get added
>> again and DAD will be triggered.  
>>
> Surely this is going to result in me sending you lots of rude emails 
> everytime cursing you when my SSH connections are terminated for no real 
> reason on a link flap?  Privacy addresses are handy on servers too such 
> as DNS servers...

No, you'd be sending me some rude emails, I didn't test that particular
case, so Dave, don't apply this.  I guess we've lived with it long enough
the way it is that dropping a few packets at initialization isn't *that*
bad.  I'll see if I can figure out a better way in the meantime...

-Brian

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] IPv6: Change addrconf code to deal with link changes better
  2010-09-11  1:10   ` Brian Haley
@ 2010-09-14  4:37     ` David Miller
  0 siblings, 0 replies; 4+ messages in thread
From: David Miller @ 2010-09-14  4:37 UTC (permalink / raw)
  To: brian.haley; +Cc: alex, netdev

From: Brian Haley <brian.haley@hp.com>
Date: Fri, 10 Sep 2010 21:10:29 -0400

> No, you'd be sending me some rude emails, I didn't test that particular
> case, so Dave, don't apply this.

Ok.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-09-14  4:37 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-10 20:58 [PATCH] IPv6: Change addrconf code to deal with link changes better Brian Haley
2010-09-10 22:27 ` Alexander Clouter
2010-09-11  1:10   ` Brian Haley
2010-09-14  4:37     ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.