• Paul Marks's avatar
    ipv6: Fix preferred_lft not updating in some cases · c9d55d5b
    Paul Marks authored
    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: default avatarPaul Marks <pmarks@google.com>
    Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    c9d55d5b
addrconf.c 125 KB