Date: Wed, 22 Jul 2020 13:45:50 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 248172] OpenVPN configuring tun/tap devices ends up with IFDISABLED interfacs Message-ID: <bug-248172-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248172 Bug ID: 248172 Summary: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfacs Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: gert@greenie.muc.de Hi, OpenVPN maintainer here. Going from FreeBSD 11 to FreeBSD 12, I discovered a new effect that I can o= nly explain by "there is a race condition in the kernel" and it affects us in non-pretty ways. What I observe: - the tun or tap interface is initialized "the normal way" (like always) - = that is, instantiate interface by open("/dev/tun0", O_RDWR), then configure by exec()'ing "ifconfig" statements for IPv4 and IPv6 - afterwards, the interface "frequently but not always" has IFDISABLED set,= and that sticks tun0: flags=3D8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=3D80000<LINKSTATE> inet6 fe80::250:56ff:fe9c:dffb%tun0 prefixlen 64 tentative scopeid = 0x3 inet6 fd00:abcd:204:2::1000 prefixlen 64 tentative inet 10.204.2.6 --> 10.204.2.5 netmask 0xffffffff groups: tun nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> Opened by PID 48722 if the interface is in this state, IPv6 will not work (you can send packets over the interface, but since the IPv6 address is marked "tentative", it wi= ll use some other IPv6 address available, which is not accepted by the server). - configuring "ifconfig tun0 inet6 -ifdisable" will always fix the problem = and make IPv6 communication work - if I add an exec() to "ifconfig tun0 inet6 -ifdisable" right after "ifcon= fig tun0 inet6 fd00:abcd:..." it will work "more often", but sometimes the IFDISABLE state still happens - if I add a sleep(1), and *then* "ifconfig -ifdisable", I can run this 100 times in a row (I did!) and never see the problem - both tun and tap are affected, but for whatever reason, it seems to happen "more frequently" for me on tap devices. But that might have been random coincidence. - Testing on older FreeBSD versions (up to and including 11.3) never exhibi= ted this sort of spurious failure. We run lots of client instance tests and I pride myself on "all tests green" :-) So - is this enough information to trigger some "oh, yes, this makes sense" moment? Or shall I provide a test program to trigger this (I do not have o= ne but could build one)? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248172-227>