[Bug 248172] OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces (problem with all ifnet, especially cloned ones)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172

--- Comment #23 from Gert Doering <gert at 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.