Skip to contentSkip to conversation

Bug 71591 - Temporary address re-generated when it should not (public address about to expire)

PATCH Heiner Kallweit 2 participants 3 messages Mar 6, 2014

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

Recently I faced the issue that a public address was about to expire and 3s before expiry a new temporary address was generated which instantly went into deprecated state. This didn't do any harm however it's wrong IMHO. Problem seems to be in function ipv6_create_tempaddr in addrconf.c.
A new temporary address is generated if this condition is met: tmp_prefered_lft > regen_advance
tmp_prefered_lft however is an offset from tstamp, not from now.
This condition only checks that the new address is preferred until more than regen_advance from tstamp,
but it should check that the new address is preferred until more than regen_advance from now.

I submitted this issue to kernel bugzilla -> 71591 Hannes asked me to propose a patch, here it comes.

Rgds, Heiner

net/ipv6/addrconf.c 2014-03-06 17:07:12.953699438 -0600 renamed from net/ipv6/addrconf.c 2014-02-22 14:41:54.000000000 -0600 +2 -1
diff -uNr linux-3.10.32.vanilla/net/ipv6/addrconf.c linux-3.10.32.patched/net/ipv6/addrconf.c
@@ -1111,8 +1111,9 @@
      * Lifetime is greater than REGEN_ADVANCE time units.  In particular,
      * an implementation must not create a temporary address with a zero
      * Preferred Lifetime.
+     * Note that tmp_prefered_lft is relative to ifp->tstamp not now.
      */
-    if (tmp_prefered_lft <= regen_advance) {
+    if (tmp_prefered_lft <= regen_advance + age) {
         in6_ifa_put(ifp);
         in6_dev_put(idev);
         ret = -1;
#1 lore raw
Quoted 13 lines · Heiner Kallweit

Recently I faced the issue that a public address was about to expire and 3s before expiry a new temporary address was generated which instantly went into deprecated state.
This didn't do any harm however it's wrong IMHO. Problem seems to be in function ipv6_create_tempaddr in addrconf.c.
A new temporary address is generated if this condition is met:
tmp_prefered_lft > regen_advance
tmp_prefered_lft however is an offset from tstamp, not from now. This condition only checks that the new address is preferred until more than regen_advance from tstamp,
but it should check that the new address is preferred until more than regen_advance from now.

Quoted 2 lines

I submitted this issue to kernel bugzilla -> 71591 Hannes asked me to propose a patch, here it comes.

You would need to follow Documentation/SubmittingPatches and provide a proper signed-off-by.

Basically if scripts/checkpatch.pl --strict doesn't complain on your patch any more, then you're ready to submit.

Otherwise the patch looks good to me.

Thanks,

Hannes

#2 lore raw

Thanks for the hint on the correct procedure. Next try ..
Output from checkpatch.p --strict
total: 0 errors, 0 warnings, 0 checks, 10 lines checked patch-3.10.32-ipv6_create_tempaddr has no obvious style problems and is ready for submission.

net/ipv6/addrconf.c 2014-03-06 17:07:12.953699438 -0600 renamed from net/ipv6/addrconf.c 2014-02-22 14:41:54.000000000 -0600 +2 -1
diff -upNr linux-3.10.32.vanilla/net/ipv6/addrconf.c linux-3.10.32.patched/net/ipv6/addrconf.c
@@ -1111,8 +1111,9 @@ retry:
      * Lifetime is greater than REGEN_ADVANCE time units.  In particular,
      * an implementation must not create a temporary address with a zero
      * Preferred Lifetime.
+     * Note that tmp_prefered_lft is relative to ifp->tstamp not now.
      */
-    if (tmp_prefered_lft <= regen_advance) {
+    if (tmp_prefered_lft <= regen_advance + age) {
         in6_ifa_put(ifp);
         in6_dev_put(idev);
         ret = -1;

Rgds,
Heiner

Am 06.03.2014 17:43, schrieb Hannes Frederic Sowa:

Quoted 29 lines · Heiner Kallweit
Quoted 13 lines

Recently I faced the issue that a public address was about to expire and 3s before expiry a new temporary address was generated which instantly went into deprecated state.
This didn't do any harm however it's wrong IMHO. Problem seems to be in function ipv6_create_tempaddr in addrconf.c.
A new temporary address is generated if this condition is met:
tmp_prefered_lft > regen_advance
tmp_prefered_lft however is an offset from tstamp, not from now. This condition only checks that the new address is preferred until more than regen_advance from tstamp,
but it should check that the new address is preferred until more than regen_advance from now.

Quoted 2 lines

I submitted this issue to kernel bugzilla -> 71591 Hannes asked me to propose a patch, here it comes.

You would need to follow Documentation/SubmittingPatches and provide a proper signed-off-by.

Basically if scripts/checkpatch.pl --strict doesn't complain on your patch any more, then you're ready to submit.

Otherwise the patch looks good to me.

Thanks,

Hannes