Bug 68444 - pppd dies in persist mode with redhats version of kernel 2.4.18
Summary: pppd dies in persist mode with redhats version of kernel 2.4.18
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ppp
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2002-07-10 09:38 UTC by Leo Bergolth
Modified: 2007-04-18 16:44 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2004-08-16 16:08:05 UTC

Attachments (Terms of Use)
syslog entries to illustrate the pppd problem (4.25 KB, text/plain)
2002-07-10 09:41 UTC, Leo Bergolth
no flags Details
dirty patch that restarts pppd after it died from this error (945 bytes, patch)
2002-07-19 09:28 UTC, Leo Bergolth
no flags Details | Diff

Description Leo Bergolth 2002-07-10 09:38:41 UTC
Description of Problem:
I'm experiencing problems after upgrading from Redhat 7.2 (kernel 2.4.9) to 7.3
(Kernel 2.4.18).

I've been using pppd (ppp-2.4.1-3 rpm) (in an ISDN-setup together with
capiplugin) for several month in persist-mode without problems with RH 7.2 and
kernel 2.4.9.
However, after the kernel upgrade, pppd dies when trying to reconnect after the
line was hung up. The problem seems to be some new kernel-code that causes the
PPPIOCDETACH ioctl to fail:

Jul  7 10:44:29 homer kernel: PPPIOCDETACH file->f_count=3

This corresponds to the following code in ppp_generic.c, which is patched in
Redhat's version of the kernel (patch: linux-2.4.17-selected-ac-bits.patch):

---------- snipp! ----------
        if (cmd == PPPIOCDETACH) {
                 * We have to be careful here... if the file descriptor
                 * has been dup'd, we could have another process in the
                 * middle of a poll using the same file *, so we had
                 * better not free the interface data structures -
                 * instead we fail the ioctl.  Even in this case, we
                 * shut down the interface if we are the owner of it.
                 * Actually, we should get rid of PPPIOCDETACH, userland
                 * (i.e. pppd) could achieve the same effect by closing
                 * this fd and reopening /dev/ppp.
                err = -EINVAL;
                if (pf->kind == INTERFACE) {
                        ppp = PF_TO_PPP(pf);
                        if (file == ppp->owner)
                if (atomic_read(&file->f_count) <= 2) {
                        ppp_release(inode, file);
                        err = 0;
                } else
                        printk(KERN_DEBUG "PPPIOCDETACH file->f_count=%d\n",
                return err;
---------- snipp! ----------

The documentation tells:
* PPPIOCDETACH detaches the instance from the channel.  This ioctl is
  deprecated since the same effect can be achieved by closing the
  instance.  In order to prevent possible races this ioctl will fail
  with an EINVAL error if more than one file descriptor refers to this
  instance (i.e. as a result of dup(), dup2() or fork()). 

# /usr/sbin/lsof /dev/ppp
pppd    24396 root    4u   CHR  108,0      1311344 /dev/ppp
pppd    24396 root   10u   CHR  108,0      1311344 /dev/ppp

Version-Release number of selected component (if applicable):

How Reproducible:

Steps to Reproduce:
1. Run pppd in persist mode.
2. Unplug the telephone line

Actual Results:
pppd fails with "Couldn't release PPP unit: Invalid argument"

Expected Results:

Additional Information:
corresponding syslog entries are attached

Comment 1 Leo Bergolth 2002-07-10 09:41:13 UTC
Created attachment 64567 [details]
syslog entries to illustrate the pppd problem

Comment 2 Leo Bergolth 2002-07-19 09:26:19 UTC
I've applied a dirty patch to ppp-watch which restarts pppd after it died from
the above error. This temporarily fixes my problem but it is not a clean
solution since pppd signals a fatal error which shouldn't be treated like that.

Comment 3 Leo Bergolth 2002-07-19 09:28:51 UTC
Created attachment 65905 [details]
dirty patch that restarts pppd after it died from this error

Comment 4 Thomas Woerner 2004-08-16 16:08:05 UTC
Please verify this with a newer version of Red Hat Enterprise Linux or
Fedora Core and reopen it against the new version if it still occurs.

Closing as "not a bug" for now.

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