Date: Thu, 25 Jul 2019 13:24:38 -0500 From: Kyle Evans <kevans@freebsd.org> To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= <trond.endrestol@ximalas.info> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, Kristof Provost <kp@freebsd.org> Subject: Re: net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045 Message-ID: <CACNAnaGXNs2oga%2Bp0-kqxkE-y2K91wmh810m0Q9u%2BBY1%2B_FRpA@mail.gmail.com> In-Reply-To: <CACNAnaEK25_9vN0uu64TyU6dHwGWVyes8RgTdkSQk6jmCgA=0A@mail.gmail.com> References: <alpine.BSF.2.21.99999.352.1907251622130.7899@enterprise.ximalas.info> <CACNAnaEK25_9vN0uu64TyU6dHwGWVyes8RgTdkSQk6jmCgA=0A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 25, 2019 at 9:46 AM Kyle Evans <kevans@freebsd.org> wrote: > > On Thu, Jul 25, 2019 at 9:41 AM Trond Endrest=C3=B8l > <trond.endrestol@ximalas.info> wrote: > > > > Hi, > > > > I have a VPN service running net/ocserv 0.12.4_1. Everything is ok > > until the first client disconnects. The main ocserv process hangs > > while destroying the tun interface, waiting indefinitely on > > "tun_cond". > > > > I ran an ocserv executable containing debug symbols through gdb and I > > had a breakpoint on the call to ioctl(fd, SIOCIFDESTROY, &ifr), at > > tun.c:770 of net/ocserv. > > > > The call to ioctl() has apparently a valid file descriptor, fd, and > > the fields of ifr are all zero, save the ifr_name field which contains > > "vpns0" and is properly null terminated. > > > > On the first attempt, I let the code run its course and had to reboot > > to recover. > > > > On the second attempt, I killed the ocserv process from within gdb. I > > ran "ifconfig vpns0 destroy" myself, and ifconfig froze immediately. > > Rebooting is the only way to recover. > > > > Reverting to stable/12 r345045 makes ocserv serve the clients again. > > > > My guess is that one or more of r345285, r347378, and/or r348124, all > > related to sys/net/if_tun.c, are to blame. > > > > Can someone verify my claims? > > > > Hi, > > I'll take a look when I get a bit- a hang on tun_cond would be > expected if a process has the tun cdev open()'d still. The device > should fail to destroy until it's closed so we don't leave the > controlling application in a funky state. There were some bugs around > that leaving the driver in a funky state that I fixed somewhere along > the way here. > > Thanks, > > Kyle Evans To follow-up to the list as well, I've added a comment on the Gitlab issue [0] -- my suspicion is that ocserv is violating the tunnel hand-off protocol (TUNSIFPID) and technically leaking the fd in the process that created it while trying to close/destroy it in another pid that actually controls the tunnel. [0] https://gitlab.com/openconnect/ocserv/issues/213
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaGXNs2oga%2Bp0-kqxkE-y2K91wmh810m0Q9u%2BBY1%2B_FRpA>