Bug 71591 - Temporary address re-generated when it should not (public address about to expire)
Subsystems (3)
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_advancetmp_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
@@ -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;
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 functionipv6_create_tempaddrinaddrconf.c.
A new temporary address is generated if this condition is met:tmp_prefered_lft>regen_advancetmp_prefered_lfthowever is an offset from tstamp, not from now. This condition only checks that the new address is preferred until more thanregen_advancefrom tstamp,
but it should check that the new address is preferred until more thanregen_advancefrom 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
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
@@ -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 functionipv6_create_tempaddrinaddrconf.c.
A new temporary address is generated if this condition is met:tmp_prefered_lft>regen_advancetmp_prefered_lfthowever is an offset from tstamp, not from now. This condition only checks that the new address is preferred until more thanregen_advancefrom tstamp,
but it should check that the new address is preferred until more thanregen_advancefrom 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/SubmittingPatchesand 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