[PATCH linux-2.6 v2] IPv6: Temp addresses are immediately deleted.
Glenn Wurster
addrconf_verify. Because ipv6_create_tempaddr uses the cstamp and tstamp
from the public address in creating a private address, if we have not
received a router advertisement in a while, tstamp + temp_valid_lft might be
< now. If this happens, the new address is created inside
ipv6_create_tempaddr, then the loop within addrconf_verify starts again and
the address is immediately deleted. We are left with no temporary addresses
on the interface, and no more will be created until the public IP address is
updated. To avoid this, set the expiry time to be the minimum of the time
left on the public address or the config option PLUS the current age of the
public interface.
Version 2, now with 100% fewer line wraps. Thanks to David Miller for
pointing out the line wrapping issue.
Signed-off-by: Glenn Wurster <gwur...@scs.carleton.ca>
---
net/ipv6/addrconf.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cfee6ae..9c74454 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -836,7 +836,7 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *i
{
struct inet6_dev *idev = ifp->idev;
struct in6_addr addr, *tmpaddr;
- unsigned long tmp_prefered_lft, tmp_valid_lft, tmp_cstamp, tmp_tstamp;
+ unsigned long tmp_prefered_lft, tmp_valid_lft, tmp_cstamp, tmp_tstamp, age;
unsigned long regen_advance;
int tmp_plen;
int ret = 0;
@@ -886,12 +886,13 @@ retry:
goto out;
}
memcpy(&addr.s6_addr[8], idev->rndid, 8);
+ age = (jiffies - ifp->tstamp) / HZ;
tmp_valid_lft = min_t(__u32,
ifp->valid_lft,
- idev->cnf.temp_valid_lft);
+ idev->cnf.temp_valid_lft + age);
tmp_prefered_lft = min_t(__u32,
ifp->prefered_lft,
- idev->cnf.temp_prefered_lft -
+ idev->cnf.temp_prefered_lft + age -
idev->cnf.max_desync_factor);
tmp_plen = ifp->prefix_len;
max_addresses = idev->cnf.max_addresses;
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller
Date: Mon, 27 Sep 2010 13:10:10 -0400
> There is a bug in the interaction between ipv6_create_tempaddr and
> addrconf_verify. Because ipv6_create_tempaddr uses the cstamp and tstamp
> from the public address in creating a private address, if we have not
> received a router advertisement in a while, tstamp + temp_valid_lft might be
> < now. If this happens, the new address is created inside
> ipv6_create_tempaddr, then the loop within addrconf_verify starts again and
> the address is immediately deleted. We are left with no temporary addresses
> on the interface, and no more will be created until the public IP address is
> updated. To avoid this, set the expiry time to be the minimum of the time
> left on the public address or the config option PLUS the current age of the
> public interface.
>
> Version 2, now with 100% fewer line wraps. Thanks to David Miller for
> pointing out the line wrapping issue.
>
> Signed-off-by: Glenn Wurster <gwur...@scs.carleton.ca>
This can only happen if we apply your other patch, which I showed
was incorrect as per RFCs.
We only create temporary address when public addresses are created,
and this is the point where we are handling a router advertisement
with non-zero Valid Lifetime.
Therefore I'm not applying this patch either.
Glenn Wurster
> From: Glenn Wurster <gwur...@scs.carleton.ca>
> Date: Mon, 27 Sep 2010 13:10:10 -0400
>
> > There is a bug in the interaction between ipv6_create_tempaddr and
> > addrconf_verify. Because ipv6_create_tempaddr uses the cstamp and tstamp
> > from the public address in creating a private address, if we have not
> > received a router advertisement in a while, tstamp + temp_valid_lft might
> > be < now. If this happens, the new address is created inside
> > ipv6_create_tempaddr, then the loop within addrconf_verify starts again
> > and the address is immediately deleted. We are left with no temporary
> > addresses on the interface, and no more will be created until the public
> > IP address is updated. To avoid this, set the expiry time to be the
> > minimum of the time left on the public address or the config option PLUS
> > the current age of the public interface.
> >
> > Version 2, now with 100% fewer line wraps. Thanks to David Miller for
> > pointing out the line wrapping issue.
> >
> > Signed-off-by: Glenn Wurster <gwur...@scs.carleton.ca>
>
> This can only happen if we apply your other patch, which I showed
> was incorrect as per RFCs.
>
> We only create temporary address when public addresses are created,
> and this is the point where we are handling a router advertisement
> with non-zero Valid Lifetime.
>
> Therefore I'm not applying this patch either.
No, the first patch was to create a temporary address if none exists. Like
Brian Haley pointed out, that patch accommodates the case where we set
use_tempaddr to a non-zero value after the interface had been brought up.
This patch accommodates the case where the router is only broadcasting
advertisements every x seconds, and yet the user has set the valid_lft to be
something less than x. In this setup, the condition I mentioned in the patch
description happens, where the new temporary address is created, but the last
modification time on that temporary address is set to the time of the last
router advertisement, which was more than valid_lft seconds ago. In this
case, the temporary address is immediately deleted, and we are left with no
temporary address on the interface. Furthermore, because all temporary
addresses get deleted by the time the next router advertisement arrives, we
are left with not being able to use temporary addresses until we move
networks.
I tested this patch alone, and it works as intended, allowing temporary
addresses to continue to be created and deleted between received router
advertisements.
You can easily test the bug by setting tmp_valid_lft to 60 and then running
radvd. The defaults for radvd seem to be a minimum retransmit on unsolicited
router advertisements of 200 seconds (http://linux.die.net/man/5/radvd.conf),
much higher than the 60 seconds it is going to take for the temporary address
to expire.
Glenn.
David Miller
Date: Sat, 16 Oct 2010 14:42:17 -0400
> This patch accommodates the case where the router is only broadcasting
> advertisements every x seconds, and yet the user has set the valid_lft to be
> something less than x. In this setup, the condition I mentioned in the patch
> description happens, where the new temporary address is created, but the last
> modification time on that temporary address is set to the time of the last
> router advertisement, which was more than valid_lft seconds ago. In this
> case, the temporary address is immediately deleted, and we are left with no
> temporary address on the interface. Furthermore, because all temporary
> addresses get deleted by the time the next router advertisement arrives, we
> are left with not being able to use temporary addresses until we move
> networks.
Thanks for the information, I'll look into this some more.
David Miller
Date: Sat, 16 Oct 2010 14:42:17 -0400
> No, the first patch was to create a temporary address if none exists. Like
> Brian Haley pointed out, that patch accommodates the case where we set
> use_tempaddr to a non-zero value after the interface had been brought up.
>
> This patch accommodates the case where the router is only broadcasting
> advertisements every x seconds, and yet the user has set the valid_lft to be
> something less than x.
Ok, thanks for your patience.
I've applied both of your patches, thanks.