|Summary:||net/ocserv: upgrading stable/12 past r345045 makes ocserv unable to reap its children, turning the VPN service into a one-shot service|
|Product:||Ports & Packages||Reporter:||Trond.Endrestol|
|Component:||Individual Port(s)||Assignee:||Kyle Evans <kevans>|
|Severity:||Affects Only Me||CC:||cpm, hrant, kevans|
Description Trond.Endrestol 2019-06-11 14:44:04 UTC
I'm stuck figuring out what causes net/ocserv to only serve the first connect on stable/12 past r345045. When a client does the very first disconnect, a couple of ocserv child processes end up as zombies. The main process is unable to serve new clients and naturally it doesn't reap its dead children. Killing the main ocserv process is futile, not even killall -kill ocserv helps. I tried stable/12 r348883 today, and it's the same story. Any pointers are appreciated.
Comment 1 Carlos J. Puga Medina 2019-06-11 16:29:19 UTC
(In reply to Trond.Endrestol from comment #0) Hi, I have not used ocserv for a long time. Have you reported the problem upstream? https://gitlab.com/openconnect/ocserv/issues
Comment 2 Trond.Endrestol 2019-06-12 06:18:24 UTC
(In reply to Carlos J. Puga Medina from comment #1) I did just now: https://gitlab.com/openconnect/ocserv/issues/213
Comment 3 Trond.Endrestol 2019-06-12 06:21:40 UTC
BZ just stated: https://gitlab.com/openconnect/ocserv/issues/213 is not a valid URL to a bug. See Also URLs should point to one of: show_bug.cgi in a Bugzilla installation. A bug on launchpad.net An issue on code.google.com. A bug on bugs.debian.org. An issue in a JIRA installation. A ticket in a Trac installation. A bug in a MantisBT installation. A bug on sourceforge.net. An issue/pull request on github.com. A review on reviews.freebsd.org. A PR on NetBSD GNATS system. An issue on Google Chromium issue tracker. An issue on bitbucket.org. I guess gitlab.com should be added to the list.
Comment 4 Carlos J. Puga Medina 2019-06-13 22:46:56 UTC
(In reply to Trond.Endrestol from comment #3) Good catch! Your request can be taken into account if you file a new PR. Thanks
Comment 5 Trond.Endrestol 2019-07-25 11:46:06 UTC
I have narrowed it down to close_tun() in tun.c:770 where ocserv tries to do ret = ioctl(fd, SIOCIFDESTROY, &ifr); All the fields in ifr are zeroed, save the ifr_name field which contains "vpns0" and is properly null terminated. The system now runs FreeBSD/amd64 12.0-STABLE r350311 and ocserv is at 0.12.4 (0.12.4_1). I killed the main ocserv process using gdb while at tun.c:770. I then ran ifconfig vpns0 destroy and ifconfig just hangs. This can very well be a bug in FreeBSD. Reverting the OS to FreeBSD/amd64 12.0-STABLE r345045 restores the VPN service. Again I can connect and disconnect as much as I like.
Comment 6 Hrant Dadivanyan 2019-09-03 20:02:38 UTC
Same story here with security/vpnc on stable/12 - service vpnc stop leaves ifconfig tun0 destroy process in D state. Manual attempt to destroy hangs as well. if_tun.c r345285 works fine.
Comment 7 Kyle Evans 2019-10-03 14:27:33 UTC
Created attachment 208060 [details] svn(1) diff against the ports tree I've proposed this patch (tested by Trond) to cpm@ via e-mail; Carlos has indicated maintainer approval via e-mail. I will seek ports committer approval to commit this and MFH it ASAP.
Comment 8 Kyle Evans 2019-10-03 14:28:25 UTC
Take; keep cpm@ apprised in CC, mark it as 'in progress'.
Comment 9 Kyle Evans 2019-10-03 14:41:21 UTC
(In reply to Hrant Dadivanyan from comment #6) Hi, Can you please submit a new PR for security/vpnc and CC me so I can fix that one as well?
Comment 10 commit-hook 2019-10-03 14:46:41 UTC
A commit references this bug: Author: kevans Date: Thu Oct 3 14:46:01 UTC 2019 New revision: 513668 URL: https://svnweb.freebsd.org/changeset/ports/513668 Log: net/ocserv: fix tun handoff between parent and worker process ocserv hands off a tun fd to a worker process, but the worker process never claims the tun with TUNSIFPID. The parent then closes the tunnel and leaves it in a nasty state. Bump PORTREVISION, as this is runtime breakage. PR: 238500 Approved by: bapt (ports), cpm (maintainer, e-mail) MFH: 2019Q4 (blanket, runtime fix) Changes: head/net/ocserv/Makefile head/net/ocserv/files/patch-src_tun.c head/net/ocserv/files/patch-src_tun.h head/net/ocserv/files/patch-src_worker-auth.c
Comment 11 Hrant Dadivanyan 2019-10-03 15:51:42 UTC
(In reply to Kyle Evans from comment #9) Hi, Kyle. The new PR 241039 is submitted and you're added to the cc list. Thank you, Hrant
Comment 12 commit-hook 2019-10-04 02:42:45 UTC
A commit references this bug: Author: kevans Date: Fri Oct 4 02:42:20 UTC 2019 New revision: 513744 URL: https://svnweb.freebsd.org/changeset/ports/513744 Log: MFH: r513668 net/ocserv: fix tun handoff between parent and worker process ocserv hands off a tun fd to a worker process, but the worker process never claims the tun with TUNSIFPID. The parent then closes the tunnel and leaves it in a nasty state. Bump PORTREVISION, as this is runtime breakage. PR: 238500 Approved by: bapt (ports), cpm (maintainer, e-mail) Approved by: ports-secteam (miwi) Changes: _U branches/2019Q4/ branches/2019Q4/net/ocserv/Makefile branches/2019Q4/net/ocserv/files/patch-src_tun.c branches/2019Q4/net/ocserv/files/patch-src_tun.h branches/2019Q4/net/ocserv/files/patch-src_worker-auth.c
Comment 13 Kyle Evans 2019-10-04 02:47:05 UTC
Thanks for the report! Closing as fixed, now that I've merged it to quarterly.