Date: Sun, 22 Nov 2020 19:20:51 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 248172] OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces (problem with all ifnet, especially cloned ones) Message-ID: <bug-248172-7501-YliZ0ZC61R@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-248172-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-248172-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172 --- Comment #23 from Gert Doering <gert@greenie.muc.de> --- (In reply to Bjoern A. Zeeb from comment #22) Bjoern, thanks for looking into this. I have stared at the diff, and it looks like a reasonable approach that solves both the "if people do not want IPv6, they should not get it" requirement, and the "but if an interface is created under program control, and the program configures IPv6, there should not be a race with a RC script that turns IPv6 back off". I have applied the patch to a 12.2-RELEASE system (kernel + /etc/rc.subr) and can confirm that it works. As in: -- it compiles :-) -- if I bring up an interface manually ("ifconfig tun7 create up"), the interface has the desired (as in: keep existing behaviour) property of "nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>" -- if I bring up the interface from within OpenVPN (open /dev/tun, exec "ifconfig ... inet6 ...", removing the "sleep(1); ifconfig ... -ifdisabled" workaround) the resulting interface has IPv6, and does not have "IFDISABLED". Since this was a race condition before - sometimes it worked, sometimes it failed - I've ran the particular test a few dozen times, with no single failure case. And no more "nd6_dad_timer: cancel DAD on tun0 because of ND6_IFF_IFDISABLED." in dmesg either :-) So, for me, this patch is the right answer :-) gert -- You are receiving this mail because: You are on the CC list for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248172-7501-YliZ0ZC61R>