ipv6: Fix preferred_lft not updating in some cases
authorPaul Marks <pmarks@google.com>
Wed, 25 Sep 2013 22:12:55 +0000 (15:12 -0700)
committerDavid S. Miller <davem@davemloft.net>
Mon, 30 Sep 2013 19:06:19 +0000 (15:06 -0400)
commitc9d55d5bff05084b5829f751aebd03d0c8f632f5
tree54aa6121beb9b2ef2301c1e8d8cbb402902be10b
parentd4a71b155c12d0d429c6b69d94076d6d57e2a7a7
ipv6: Fix preferred_lft not updating in some cases

Consider the scenario where an IPv6 router is advertising a fixed
preferred_lft of 1800 seconds, while the valid_lft begins at 3600
seconds and counts down in realtime.

A client should reset its preferred_lft to 1800 every time the RA is
received, but a bug is causing Linux to ignore the update.

The core problem is here:
  if (prefered_lft != ifp->prefered_lft) {

Note that ifp->prefered_lft is an offset, so it doesn't decrease over
time.  Thus, the comparison is always (1800 != 1800), which fails to
trigger an update.

The most direct solution would be to compute a "stored_prefered_lft",
and use that value in the comparison.  But I think that trying to filter
out unnecessary updates here is a premature optimization.  In order for
the filter to apply, both of these would need to hold:

  - The advertised valid_lft and preferred_lft are both declining in
    real time.
  - No clock skew exists between the router & client.

So in this patch, I've set "update_lft = 1" unconditionally, which
allows the surrounding code to be greatly simplified.

Signed-off-by: Paul Marks <pmarks@google.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/ipv6/addrconf.c