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.
I believe this is fixed in current beta initscripts. Please check there.
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...
*** Bug 97850 has been marked as a duplicate of this bug. ***
Some of this is fixed in initscripts-7.32-1.
Woops, make that 7.33-1.
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].
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.
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