net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045

[Kyle Evans]

On Thu, Jul 25, 2019 at 9:46 AM Kyle Evans <kevans at freebsd.org> wrote:
>
> On Thu, Jul 25, 2019 at 9:41 AM Trond Endrestøl
> <trond.endrestol at 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