Date: Thu, 25 Jul 2019 09:46:58 -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: <CACNAnaEK25_9vN0uu64TyU6dHwGWVyes8RgTdkSQk6jmCgA=0A@mail.gmail.com> In-Reply-To: <alpine.BSF.2.21.99999.352.1907251622130.7899@enterprise.ximalas.info> References: <alpine.BSF.2.21.99999.352.1907251622130.7899@enterprise.ximalas.info>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaEK25_9vN0uu64TyU6dHwGWVyes8RgTdkSQk6jmCgA=0A>