Bug 241039 - security/vpnc can not destroy tun device on exit
Summary: security/vpnc can not destroy tun device on exit
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Steve Wills
Depends on:
Reported: 2019-10-03 15:45 UTC by Hrant Dadivanyan
Modified: 2019-12-16 16:29 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback?

svn(1) diff against the ports tree (3.50 KB, patch)
2019-10-03 15:51 UTC, Kyle Evans
kevans: maintainer-approval? (ehaupt)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hrant Dadivanyan 2019-10-03 15:45:48 UTC

After last changes to tun device in stable/12, security/vpnc is unable to destroy its tun device on exit. service vpnc stop leaves ifconfig tun0 destroy process in D state.
Manual attempt to destroy tun device hangs as well.
Reverting if_tun.c back to r345285 restores expected behavior.

This looks similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238500

Thank you,
Comment 1 Kyle Evans freebsd_committer 2019-10-03 15:51:59 UTC
Created attachment 208067 [details]
svn(1) diff against the ports tree


Please try the attached patch- it had the same issue as net/ocserv in that the forked child didn't do the tunnel hand-off properly.


Kyle Evans
Comment 2 Hrant Dadivanyan 2019-10-03 17:44:10 UTC
Indeed, the patch works.
Thank you, Kyle!
Comment 3 Emanuel Haupt freebsd_committer 2019-10-04 08:27:08 UTC
This might fix it for people running stable/12 but will break it for everyone on a lower version.

There should be at least some version handling in the code. Can you pinpoint the change that caused the breakage?

Comment 4 Kyle Evans freebsd_committer 2019-10-04 11:51:28 UTC
No, there should be no breakage. TUNSIFPID has existed for about 20 years and is technically how this should have happened all along. It will do no harm in earlier branches (except now ifconfig output will now reflect actual pid using the tunnel)
Comment 5 Emanuel Haupt freebsd_committer 2019-10-04 12:46:07 UTC
Unfortunately I do not have any accounts to test this with. I've just released maintainership of this port. Assign bug back to queue.
Comment 6 Jesse Espinoza 2019-10-04 18:30:10 UTC
Hi Kyle Evans,

I had the same problem. Couldn't destroy the tunnel interface, and everytime I re-started vpnc it would increment a new tunnel name (tun4, tun5, tun6 etc...). This would break my firewall and nat rules.

I have confirmed this patch works on my custom setup on OpnSense running the following:

OPNsense 19.7.4_1-amd64
OpenSSL 1.0.2s 28 May 2019


Comment 7 Kyle Evans freebsd_committer 2019-10-06 02:20:45 UTC
I guess I'm taking it, now that it's unmaintained. =-)

I did relax the misbehavior in head because software's not quite ready for it. I'd still like to commit this, because I turned it into a syslog message nagging that the tun was ultimately closed by not-the-controller.
Comment 8 Jesse Espinoza 2019-12-16 15:58:39 UTC
(In reply to Kyle Evans from comment #7)
Hi Kyle,

Is there a reason why this fix hasn't been released to ports?


We are still seeing the issue and the old version on ports (v0.5.3_13). How can I help?


Comment 9 Kyle Evans freebsd_committer 2019-12-16 16:08:51 UTC
(In reply to Jesse Espinoza from comment #8)

Hmm... sorry about that, I didn't realize the strict behavior had made it into 11.3, so it's only fixed on stable branches and head/ -- thus, I dropped the ball. =-(

I'll poke some ports people to see if I can get it approved or committed.
Comment 10 commit-hook freebsd_committer 2019-12-16 16:29:35 UTC
A commit references this bug:

Author: swills
Date: Mon Dec 16 16:28:33 UTC 2019
New revision: 520267
URL: https://svnweb.freebsd.org/changeset/ports/520267

  security/vpnc: fix issue with destroying tun device on exit

  While here, improve formatting and regenerate patches

  PR:		241039
  Submitted by:	kevans
  Reported by:	Hrant Dadivanyan <hrant@dadivanyan.net>

Comment 11 Steve Wills freebsd_committer 2019-12-16 16:29:46 UTC
Committed, thanks!