I've run into a problem setting up some PPP tunnels over SSL and I've come to the realization that either ppp-watch and/or ifup-ppp are dain bramaged. I think that ifup-ppp has a bug (calling ppp-watch with the wrong parameters) but I also am coming to the conclusion that ppp-watch never worked right to begin with.
Reasons... Simple...
1) If logical name != DEVICE name (DEVICE= in config) it doesn't work
at all and the error message are worse than stupid.
2) Calling parameters in ifup-ppp to ppp-watch do NOT MATCH
the program parameters in ppp-watch.
3) Man page on ppp-watch is not only totally worthless, it's flat
out wrong with false information. The calling parameters in the man page
are not the calling parameters in the sources to ppp-watch.
My situation...
I have a laptop that has three different PPP configurations.
Configuration 1: Dialup to Earthlink/Sprint/Mindspring via /dev/modem.
Configuration 2: Cell phone USB to Sprint pcsvision via
/dev/input/ttyACM0
Configuration 3: PPP over stunnel via ethernet back to a gateway.
Looking over scripts, it seems pretty obvious...
For connection "amber" (the ppp over stunnel/ssh/your transport of
choice)...
Set up a file "ifcfg-amber" with appropriate IP information and
"DEVICE=ppp0". Set up ppp options file "/etc/ppp/peers/amber" with
appropriate connection information. Option "pty command" sets the
tunnel command.
Run "ifup amber".
It doesn't work. The ppp-watch program errors out saying connection
failed "error 28" with no error in syslog. Seems that ppp-watch got invoked
as follows: "ppp-watch ppp0 ifcfg-amber" and then looks for ifcfg-ppp0 and
doesn't like the fact that it doesn't exist. To say the error message is
"less than informative" is the understatement of the year. Ok... Create
that file... Then is says "error 1". Well, now I have a pppd error in
syslog saying it can't fine /etc/ppp/peers/ppp0. But that wasn't the
file is was suppose to access! So I copy the amber file to ppp0 and it
starts up and establishes the connection but hangs. If I control C the
bugger, ppp-watch complains that it couldn't start the connection, error 35
this time, but the connection and pppd are both up! Unfortunately, the
one thing wrong with that ppp connection is that pppd is called with a
connection name of "ppp0" which is not what I wanted at all.
So... I ran ppp-watch by hand with no parameters and it tells me
the calling parameters are "ppp-watch [ifcfg-]<logical-name> [boot]".
But the man page says... "ppp-watch interface-name interface-name [boot]".
Ok... As Yoda says, use the source Luke... The sources for ppp-watch
are very clear.
=============================================================================
] if (argc < 2) {
] fprintf (stderr, "usage: ppp-watch [ifcfg-]<logical-name> [boot]\n");
] exit(30);
] }
]
] if (strncmp(argv[1], "ifcfg-", 6) == 0) {
] device = argv[1] + 6;
] } else {
] device = argv[1];
] }
]
] detach(device); /* Prepare a child process to monitor pppd. When we
] return, we'll be in the child. */
]
] if ((argc > 2) && (strcmp("boot", argv[2]) == 0)) {
] boot = argv[2];
] }
=============================================================================
Answer turns out to be "NONE OF THE ABOVE!"
Both the man pages AND usage message are WRONG! It REQUIRES TWO
parameters (argc < 2). If the second parameter ain't "boot", it nulls
it out before forking off.
But ifup-ppp calls ppp-watch like this:
=============================================================================
]
] source_config
] # don't start ppp-watch by xDSL
] [ "$TYPE" = "xDSL" ] || exec /sbin/ppp-watch "${DEVICE}" "$@"
]
=============================================================================
The "DEVICE" parameter can not be null or you would not have
gotten to this script from "ifup" since "DEVICETYPE" is derived from
stripping the trailing numbers from that same "DEVICE" variable from
that same file.
This script was called from ifup like this:
=============================================================================
]if [ -x ${OTHERSCRIPT} ]; then
] exec ${OTHERSCRIPT} ${CONFIG} $2
]fi
=============================================================================
So ifup-ppp gets called with two parameters, the configuration
file name and the second parameter to the ifup command (boot during
booting). So ppp-watch can only ever be called with the device name
from the config file followed by the configuration file name in the
second parameter followed by an optional third parameter which may be
"boot". But it's expecting the "boot" parameter in the second parameter,
not the third and the second parameter will always be ifcfg-{something}
so it can never be "boot"!
So the man page is WRONG and ifup-ppp is calling ppp-watch with
the wrong set of parameters and it seems like it's working at all only
through sheer dumb luck and the "boot" parameter is going to get totally
lost because of the extra parameter. A "non-boot" ifup is only going to
work because of the bogus extra parameter and the "boot" bootup ain't
going to have a "boot" timeout (another BUG that I've observed in real
life).
I've verified this dain bramage on RedHat 7.2, 7.3 and 8.0.
The whole ppp-watch thing is so broken as to defy belief. Not that
it's broken but rather that, but pure happenstance of bugs, it just gets
lucky and works at all in the case where the device name and the logical
config name are the same.
Anyone have ideas of how this should be fixed properly? The
obvious course would seem to be to drive a stake through the heart of
ppp-watch and modify the ifup-ppp scripts...
Mike
--
Michael H. Warfield | (770) 985-6132 | [EMAIL PROTECTED]
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
pgp00000.pgp
Description: PGP signature
