Bug 85447 - ppp-watch called with wrong parameters from ifup-ppp. Peer names inoperative. Boot timeouts inoperative.
ppp-watch called with wrong parameters from ifup-ppp. Peer names inoperative...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
bzcl34nup
:
: 97850 (view as bug list)
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2003-03-02 17:51 EST by Michael H. Warfield
Modified: 2014-03-16 22:34 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 19:55:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael H. Warfield 2003-03-02 17:51:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203

Description of problem:
Paramters to ppp-watch in the C code do not agree with parameters in usage
message and neither of which agree with documentation.  Furthermore, ifup-ppp
uses the parameters described in the documentation, which is flat out WRONG. 
When using a "peer name", such as "amber", ifup-ppp calls ppp-watch as follows:
"ppp-watch ppp0 ifcfg-amber".  But ppp-watch expects the second parameter to be
"boot" or nothing and ignores it and tries to use the peer "ppp0" instead which
is WRONG.

Side note to this...  Boot up timeouts for ppp-watch are also busted.  Because
the second parameter is the configuration file name and never "boot", the "boot"
timeout mode is never invoked.

Contrary to the usage statement, the second parameter is not optional.  The
ppp-watch code explicitly requires two parameters.

This has been confirmed on RedHat 7.2, 7.3, and 8.0.

As a side side note...  The assinine error messages from ppp-watch are worse
than useless.  Failed to start interface ppp0 error 28 is totally BOGUS and
tells you nothing about WHY it failed.  The fact that it could not find
"ifcfg-ppp0" even though you wanted it to use "ifcfg-amber" was the real issue.

Seems as though any case where the configuration file and the DEVICE= in that
file disagree for a ppp device is busted.  In addition to the bootup parameters
being busted.

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


How reproducible:
Always

Steps to Reproduce:
1. Create ppp connect file "ifcfg-amber" - no "ifcfg-ppp0"
2. Run ifup amber
3. Error unable to activate interface error 28
4. Create "ifcfg-ppp0"
5. Run ifup amber
6. Error unable to activate interface error 1
   (Syslog indicates error that /etc/ppp/peers/ppp0 doesn't exist).

    

Actual Results:  Errors noted above.  Wrong link name to ppp.

Expected Results:  Use /etc/ppp/peers/amber to establish connection and bring up
new ppp connection.

Additional info:

Details are in the description.  The two software modules do not agree in the
calling parameters to ppp-watch and are just broken.
Comment 1 Bill Nottingham 2003-03-03 16:27:44 EST
I believe this is fixed in current beta initscripts. Please check there.
Comment 2 Michael H. Warfield 2003-03-09 17:06:51 EST
This is just based on code examination.  I don't have a spare machine to bring
up a beta of RedHat 8.1 on right at the moment.  Results of the code examination
do NOT look promising, IAC...

Still looks busted.

Just busted in a different way.  The parameter errors calling ppp-watch are
"fixed" but now it's being called with the WRONG peername.  So if DEVICE doesn't
agree with the name of the config file, you call pppd with with wrong peer name
of "ppp?" instead of "amber" or "green" or what ever you wanted it to be called.
 That also means the link name is busted AND you can't have multiple definitions
for the same "ppp" device ("amber" builds an ssl tunnel, sprint does a ppp dial
to ttyACM0, earthlink does a landline dial through a modem).  It also means
that, even though you have an "ifcfg-amber", it won't work unless you ALSO have
an "ifcfg-ppp0" because ppp-watch is going to look for the "ppp0" config
file.

Documenation on ppp-watch is also still wrong.  Usage statement from program
indicates the second parameter is optional but the "if" check on argc requires
at least two parameters.

I think these four lines from ppp-watch.c say it all...

    if (argc < 2) {
        fprintf (stderr, "usage: ppp-watch [ifcfg-]<logical-name> [boot]\n");
        exit(30);
    }

Anything less than two parameters and you generate the usage error, but the
usage message, incorrectly, states the second parameter is optional.  What's
unclear here?

This also means that if "ifup-ppp" gets called by hand ($2 = NULL) then argc
will be 1 and the command will fail.  So I guess we can forget about manually
starting ppp connections.

Man page for ppp-watch has been "corrected" to agree with the usage statement
but neither of them agree with what the code does!

Still broken...
Comment 3 Bill Nottingham 2003-09-03 23:59:48 EDT
*** Bug 97850 has been marked as a duplicate of this bug. ***
Comment 4 Bill Nottingham 2003-09-15 01:37:44 EDT
Some of this is fixed in initscripts-7.32-1.
Comment 5 Bill Nottingham 2003-09-15 01:41:03 EDT
Woops, make that 7.33-1.
Comment 6 Miloslav Trmač 2006-02-28 20:15:22 EST
AFAICS this should all work fine, but I have not tested it.

"these four lines" in comment #2 are actually correct, argc includes argv[0].
Comment 7 Bug Zapper 2008-04-03 11:26:48 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 8 Bug Zapper 2008-05-06 19:55:32 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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