On September 29, 2010 02:30:28 am David Miller wrote:

From: Glenn Wurster <redacted>
Date: Mon, 27 Sep 2010 13:10:10 -0400

quoted

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 <redacted>

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.