Bug 665364 - unregister_netdevice: waiting for ppp0 to become free. Usage count = 3
Summary: unregister_netdevice: waiting for ppp0 to become free. Usage count = 3
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: openswan
Version: 14
Hardware: i686
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Avesh Agarwal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 665863 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-23 12:55 UTC by Rolf Fokkens
Modified: 2012-03-06 20:08 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-06 20:08:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch to disable -DTRUST_PPPD_TO_DIE (685 bytes, text/plain)
2011-02-23 15:51 UTC, Rolf Fokkens
no flags Details
SPEC file to disable -DTRUST_PPPD_TO_DIE (13.35 KB, text/plain)
2011-02-23 15:53 UTC, Rolf Fokkens
no flags Details

Description Rolf Fokkens 2010-12-23 12:55:49 UTC
Description of problem:
I successfully can create VPN tunnels from OS-X following the directions 
http://www.mindbug.org/2010/11/fedora-as-ipsecl2tp-vpn-server-for-mac.html

After disconnecting from OS-X the linux kernel complains:
unregister_netdevice: waiting for ppp0 to become free. Usage count = 3

It looks like pppd cannot be killed after this happens, according to strace it's stuck in close (10), and they finaly seem to die after a "service ipsec stop".

Version-Release number of selected component (if applicable):
openswan-2.6.31-1.fc14.i686
xl2tpd-1.2.7-1.fc14.i686
ppp-2.4.5-12.fc14.i686
kernel-2.6.35.9-64.fc14.i686

How reproducible:
100%

Steps to Reproduce:
1. Configure a VPN tunnel as described
2. Make a successfull VPN connection from a OS-X 10.6.5
3. Disconnect the VPN from the OS-X side
4. Enjoy the "unregister_device" messages in the syslog
5. Find out that no more VPN connections can be established
  
Actual results:
Message in syslog:
unregister_netdevice: waiting for ppp0 to become free. Usage count = 3
Impossible to establish another VPN connection

Expected results:
Clean disconnect of the VPN, ability to reconnect.

Additional info:

Comment 1 Rolf Fokkens 2010-12-23 12:58:43 UTC
The close(10) of pppd refers to /dev/ppp

Comment 2 Paul Wouters 2011-02-08 18:26:59 UTC
This would be a bug in the ppp package, not in the openswan package.

The xl2tpd has an option for pppds that are unwilling to die, but the pppd version in fedora should be new enough not to have that bug in it. 

But if you want to try, recompile xl2tpd and remove -DTRUST_PPPD_TO_DIE from DFLAGS and let us know if that resolves your problem

Comment 3 Paul Wouters 2011-02-23 05:00:25 UTC
Note that an inherient problem with removing that define is that any cleanup that pppd normally does via /etc/ppp/ip-down would not be run, as xl2tpd would kill pppd before it got a chance to run those.

Comment 4 Rolf Fokkens 2011-02-23 15:51:22 UTC
Created attachment 480500 [details]
Patch to disable -DTRUST_PPPD_TO_DIE

Comment 5 Rolf Fokkens 2011-02-23 15:53:10 UTC
Created attachment 480502 [details]
SPEC file to disable -DTRUST_PPPD_TO_DIE

Comment 6 Rolf Fokkens 2011-02-23 15:55:38 UTC
Ik rebuilt the xl2tpd package using the attached diff and spec file, attempting to disable -DTRUST_PPPD_TO_DIE. During build of the package the -DTRUST_PPPD_TO_DIE no longer shows up.

After installing the newly built package, the problem remains.

Comment 7 Paul Wouters 2011-10-06 19:31:41 UTC
I cannot reproduce this. I only have OSX 10.7.1 though. I was also behind NAT.

Is this still an issue with "current" openswan and xl2tpd and kernel?

Comment 8 Paul Wouters 2011-10-06 19:32:02 UTC
*** Bug 665863 has been marked as a duplicate of this bug. ***

Comment 9 Rolf Fokkens 2011-10-11 19:56:34 UTC
I will get back on this one, but it requires some effort to test this again.

Comment 10 Rolf Fokkens 2011-10-15 21:34:49 UTC
Rebuilt my own NAT network configuration, and tested again. Good news: things seem to work fine now!


Note You need to log in before you can comment on or make changes to this bug.