Launchpad has imported 7 comments from the remote bug at https://bugzilla.kernel.org/show_bug.cgi?id=13221.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-05-01T21:22:33+00:00 stlman wrote: Temporary addresses aren't regenerated properly if: 1) temp_prefered_lft - desync_factor < ADDR_CHECK_FREQUENCY. Address verification do not schedule generating of a new address but deprecates the address during the first verification after it is created. 2) temp_valid_lft changes between verifications so that there is no chance for an address to become deprecated. If any of the above happens there is no chance to create new valid and preferred temporary address because they are created only when: 1) a new public is created 2) a temporary address is going to be deprecated. (it needs to be verified at least ones as valid and preferred in addrconf_verify()) All in all we end up with no temporary address and no chance to get one. PS. I'll try to work it out this weekend. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381896/comments/0 ------------------------------------------------------------------------ On 2009-05-01T21:45:58+00:00 stlman wrote: Yet another problem is that desync_factor is constant and equal max_desync_factor (i.e. 10 minutes) which makes it completly useles. RFC says: The value DESYNC_FACTOR is a random value (different for each client) that ensures that clients don't synchronize with each other and generate new addresses at exactly the same time. When the preferred lifetime expires, a new temporary address is generated using the new randomized interface identifier. so i suppose it will be ok if there is a single value for all interfaces generated in addrconf_init and probably regenerated when max_desync_factor is set to a value that is lower then the current value of the desync_factor. BTW, rfc doesn't say anything about max_desync_factor being tunable. Should it be? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381896/comments/1 ------------------------------------------------------------------------ On 2009-05-03T21:23:32+00:00 stlman wrote: Created attachment 21201 More elaborate fix of temporary address assgnment. This patch fixes issues with temporary address assignment and improper expiration. Described in bug #13208. It also implements RFC-compliant DESYNC_FACTOR variable that prevents clients form synchronizing in address reassignment. The patch has been created against Linux 2.6.30-rc4. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381896/comments/2 ------------------------------------------------------------------------ On 2009-05-03T21:24:45+00:00 stlman wrote: *** Bug 13208 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381896/comments/3 ------------------------------------------------------------------------ On 2009-05-04T13:36:04+00:00 stlman wrote: Created attachment 21208 Next revision of the same patch. This is the same patch as before with some issues ironed. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381896/comments/4 ------------------------------------------------------------------------ On 2009-05-05T21:27:56+00:00 akpm wrote: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). Someone seems to have just unbusted something at bugzilla.kernel.org and I'm being flooded with old bugzilla reports. On Fri, 1 May 2009 21:22:34 GMT bugzilla-dae...@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13221 > > Summary: IPv6 Privacy extension, temporary are not regenerated > properly. This one has patches attached. Please send patches via email, not via bugzilla. Let's start again on this one. Please send a fresh, fully changelogged patch to the ipv6 maintainers and mailing list (available in ./MAINTAINERS). Thanks. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381896/comments/5 ------------------------------------------------------------------------ On 2009-05-05T21:30:51+00:00 davem wrote: From: Andrew Morton <a...@linux-foundation.org> Date: Tue, 5 May 2009 14:25:36 -0700 > Let's start again on this one. Please send a fresh, fully changelogged > patch to the ipv6 maintainers and mailing list (available in ./MAINTAINERS). He already did this the other day. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381896/comments/6 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/381896 Title: bad router advertisement lead to disabilitation of ipv6 privacy extension Status in Linux: Fix Released Status in linux package in Ubuntu: Incomplete Bug description: Binary package hint: linux-source After enabling IPV6 privacy extension (with echo 2 > /proc/sys/net/ipv6/conf/eth8/use_tempaddr) ubuntu autoconfigs, as aspected, ipv6-privacy-extension-addresses and they change every 60 seconds makeing outgoing connection droped every 60 seconds (radvd running on 6to4 prefix with AdvPreferredLifetime 20 and AdvValidLifetime 30). After changing AdvValidLifetime to 300 in radvd (on the router) ubuntu starts getting assigned more and more addresses up to about 15. Changing AdvValidLifetime back to 30 lead ubuntu to deconfigure ALL ipv6-privacy-extension-addresses addresses leaving the interface with only the stateless address but interface is still configured to use privacy extension but it's no longer used. So privacy is no longer ensured without any user command but just some crafted ra packets. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/381896/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
