From owner-freebsd-stable@freebsd.org Thu Jul 25 18:25:11 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D5203AAF9C for ; Thu, 25 Jul 2019 18:25:11 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7D6B8EEA1; Thu, 25 Jul 2019 18:25:11 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 6900F9457; Thu, 25 Jul 2019 18:25:11 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-wr1-f43.google.com with SMTP id y4so51809229wrm.2; Thu, 25 Jul 2019 11:25:11 -0700 (PDT) X-Gm-Message-State: APjAAAWwxVTN/XCZeqK6Wjet/pHlX2wTBaYAR0Q7k3t3aPq632nDENoR 6QC85CTQ0OUTiExkl4et79oG537RVr1UXtwoc0E= X-Google-Smtp-Source: APXvYqw1fvJcUjnyWGGYlMxfakObCBzdrnur9xHFSvu4VcEuRO+1HuAsbj5DS5rKBMUbyckxpzGGJERSsnQNbC5SROI= X-Received: by 2002:adf:ce88:: with SMTP id r8mr22633199wrn.42.1564079110334; Thu, 25 Jul 2019 11:25:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Thu, 25 Jul 2019 13:24:38 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: net/ocserv (and ifconfig) unable to destroy tun interfaces post r345045 To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: FreeBSD-STABLE Mailing List , Kristof Provost Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B7D6B8EEA1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.975,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 18:25:11 -0000 On Thu, Jul 25, 2019 at 9:46 AM Kyle Evans wrote: > > On Thu, Jul 25, 2019 at 9:41 AM Trond Endrest=C3=B8l > 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