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 <bj...@mork.no> 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 <han...@stressinduktion.org> Cc: åè¤è±æ <hideaki.yoshif...@miraclelinux.com> Signed-off-by: Bjørn Mork <bj...@mork.no> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> Signed-off-by: David S. Miller <da...@davemloft.net> (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....)
pgp7t7dQRSLiQ.pgp
Description: PGP signature