On Thu, Jul 25, 2019 at 9:41 AM Trond Endrestøl <trond.endres...@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 _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
