freebsd stable - Jul 2019 - net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045

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?

See also:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238500
https://gitlab.com/openconnect/ocserv/issues/213

-- 
Trond.

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