Bug 238500

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 Endrestøl <Trond.Endrestol>
Component: Individual Port(s)Assignee: Kyle Evans <kevans>
Status: Closed FIXED    
Severity: Affects Only Me CC: cpm, hrant, kevans
Priority: --- Flags: cpm: maintainer-feedback+
kevans: merge-quarterly+
Version: Latest   
Hardware: Any   
OS: Any   
URL: https://gitlab.com/openconnect/ocserv/issues/213
Attachments:
Description Flags
svn(1) diff against the ports tree kevans: maintainer-approval+

Description Trond Endrestøl 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 freebsd_committer freebsd_triage 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 Endrestøl 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 Endrestøl 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 freebsd_committer freebsd_triage 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 Endrestøl 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 2019-10-03 14:28:25 UTC 
Take; keep cpm@ apprised in CC, mark it as 'in progress'.
Comment 9 Kyle Evans freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 2019-10-04 02:47:05 UTC 
Thanks for the report! Closing as fixed, now that I've merged it to quarterly.