IPv6 patch mysteriously breaks IPv4 VPN

[Valdis Kletnieks]

I'll say up front - no, I do *not* have a clue why this commit causes this
problem - it makes exactly zero fsking sense.

Scenario:  $WORK is blessed with a Juniper VPN system.  I've been
seeing for a while now (since Dec-ish) an issue where at startup,
the tun0 device will get wedged.  ifconfig reports this:

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
        inet 172.27.1.165  netmask 255.255.255.255  destination 172.27.1.165
        inet6 fe80::6802:d95c:f3f4:2a6f  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 48 (48.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

and no more packets cross - not even a ping.

Yes, the tunnel is ipv4 only, and only ipv4 routes get set by the VPN software.

bisect results confirmed - linux-next 20160327 is bad, but 20160420 with this
one conmmit reverted works.

% git bisect bad                  
cc9da6cc4f56e05cc9e591459fe0192727ff58b3 is the first bad commit
commit cc9da6cc4f56e05cc9e591459fe0192727ff58b3
Author: BjÃÂrn Mork <bjorn@xxxxxxx>
Date:   Wed Dec 16 16:44:38 2015 +0100
                                
    ipv6: addrconf: use stable address generator for ARPHRD_NONE
                                
    Add a new address generator mode, using the stable address generator
    with an automatically generated secret. This is intended as a default
    address generator mode for device types with no EUI64 implementation.
    The new generator is used for ARPHRD_NONE interfaces initially, adding
    default IPv6 autoconf support to e.g. tun interfaces.
    
    If the addrgenmode is set to 'random', either by default or manually,
    and no stable secret is available, then a random secret is used as
    input for the stable-privacy address generator.  The secret can be
    read and modified like manually configured secrets, using the proc
    interface.  Modifying the secret will change the addrgen mode to
    'stable-privacy' to indicate that it operates on a known secret.
    
    Existing behaviour of the 'stable-privacy' mode is kept unchanged. If
    a known secret is available when the device is created, then the mode
    will default to 'stable-privacy' as before.  The mode can be manually
    set to 'random' but it will behave exactly like 'stable-privacy' in
    this case. The secret will not change.
    
    Cc: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
    Cc: ÃÂÂÃÂÂÃÂÂÃÂÂ <hideaki.yoshifuji@xxxxxxxxxxxxxxxx>
    Signed-off-by: BjÃÂrn Mork <bjorn@xxxxxxx>
    Acked-by: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
    Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>

(Sorry for the delay in reporting this - bisecting this proved to be
a bear and a half, because this problematic commit landed only about 10 commits after
this one: 

git bisect start
# good: [1bd4978a88ac2589f3105f599b1d404a312fb7f6] tun: honor IFF_UP in tun_get_user()

which fixed a *different* issue that prevented the tun device from getting
created at all (or it was immediately taken back down by the VPN software).
End result was that unless I gave a "known good" start point in that dozen
commit range, there's be a month's worth of 'git commit skip' to wade through.
I got damned lucky and found a record on one of my servers of an ssh over VPN,
and correlated it to the one day that linux-next had the above fix for the
previous issue, and wasn't broken by this current issue....)

Attachment: pgpmykXiAIsye.pgp
Description: PGP signature