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

Kyle Evans kevans at freebsd.org
Thu Jul 25 14:47:32 UTC 2019


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


More information about the freebsd-stable mailing list