https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248172
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: b...@freebsd.org
Reporter: g...@greenie.muc.de
Hi,
OpenVPN maintainer here.
Going from FreeBSD 11 to FreeBSD 12, I discovered a new effect that I can only
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=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<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=29<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 will
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 "ifconfig
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 exhibited
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 one
but could build one)?
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
