From owner-freebsd-bugs@freebsd.org Wed Jul 22 13:45:51 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3371837CDD1 for ; Wed, 22 Jul 2020 13:45:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BBcDb0hH7z4Cwq for ; Wed, 22 Jul 2020 13:45:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1783E37CDD0; Wed, 22 Jul 2020 13:45:51 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1745C37D01C for ; Wed, 22 Jul 2020 13:45:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BBcDZ6x56z4CtD for ; Wed, 22 Jul 2020 13:45:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D152A8496 for ; Wed, 22 Jul 2020 13:45:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 06MDjojl019941 for ; Wed, 22 Jul 2020 13:45:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 06MDjonR019940 for bugs@FreeBSD.org; Wed, 22 Jul 2020 13:45:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 248172] OpenVPN configuring tun/tap devices ends up with IFDISABLED interfacs Date: Wed, 22 Jul 2020 13:45:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gert@greenie.muc.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 13:45:51 -0000 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 metric 0 mtu 1500 options=3D80000 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 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.=