Bug 85447

Summary: ppp-watch called with wrong parameters from ifup-ppp. Peer names inoperative. Boot timeouts inoperative.
Product: [Fedora] Fedora Reporter: Michael H. Warfield <mhw>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: barryn, denis, mitr, mitr, rvokal, triage
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 23:55:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150221    

Description Michael H. Warfield 2003-03-02 22:51:43 UTC
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 21:27:44 UTC
I believe this is fixed in current beta initscripts. Please check there.

Comment 2 Michael H. Warfield 2003-03-09 22:06:51 UTC
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-04 03:59:48 UTC
*** Bug 97850 has been marked as a duplicate of this bug. ***

Comment 4 Bill Nottingham 2003-09-15 05:37:44 UTC
Some of this is fixed in initscripts-7.32-1.

Comment 5 Bill Nottingham 2003-09-15 05:41:03 UTC
Woops, make that 7.33-1.

Comment 6 Miloslav Trmač 2006-03-01 01:15:22 UTC
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 15:26:48 UTC
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 23:55:32 UTC
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