On Thu, Jul 25, 2019 at 9:46 AM Kyle Evans <kev...@freebsd.org> wrote: > > 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
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 _______________________________________________ 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"
