It seems that the underlying problem here is that pppd (Debian version
2.4.3-20050321+2) will segfault if you try to use the "call" option more
than once. It has nothing specifically to do with nested use of this
option. This is a new bug; previous versions did not have this problem.
I use pppd like this:
/usr/sbin/pppd call netctrl call myaccount
The file /etc/ppp/peers/netctrl contains:
noauth
defaultroute
/dev/ttyS2
115200
linkname inet
idle 1200
The file /etc/ppp/peers/myaccount contains:
user joe
password abcxyz
The purpose of this is to separate the hardware configuration from the
dialup account information. I also use a standard /etc/ppp/options file
and a "connect" script, but these don't appear to be relevant to the
matter at hand. This all worked fine until I upgraded to the current ppp
version. Now this command segfaults immediately:
/usr/sbin/pppd call netctrl call myaccount dryrun
However, when I concatenate the two config files together, so as to use
a single "call" option, everything works fine; the command prints all
the options and exits normally:
/usr/sbin/pppd call test dryrun
It does not appear that any /var/run/ppp* files are created in either
case; the segfault happens even when these are removed beforehand.
GDB backtrace:
$ gdb /usr/sbin/pppd core
GNU gdb 6.3-debian
...
(gdb) bt
#0 0x08074fd2 in tdb_store ()
#1 0x08051b80 in unlock_db ()
#2 0x08061a11 in int_option ()
#3 0x08060b3b in options_from_list ()
#4 0x080601ef in parse_args ()
#5 0x0804ee59 in main ()
(gdb)
-- which looks pretty much the same as what some other people reported
previously.
To summarize, this bug is simple to reproduce; just use the "call"
option twice. It does not depend on the specific contents of the options
files, or using "call" in nested files. A comparison of the relevant
code section with the previous version should find it; it's probably
something trivial, like some variable not being properly reinitialized
the second time it's used. Using "call" more than once always used to
work, and it seems like a reasonable thing to want to do. It might be
worth investigating the "file" option to see if it now exhibits the same
problem.
A related issue: I'd like to suggest that the secret "password" option
be documented in the manual page. I only found it when I was digging
through the source code trying to figure out how to implement such a
feature; it turned out that somebody already had. When I asked the
upstream maintainers why it wasn't documented, they said that this was
because using it on the command line would be a security hole, as the
authentication password would be exposed by "ps". The simple solution to
that problem is to disallow it on the command line, and only accept it
through the "call" and "file" options. This is the reason why I was
using a "call" option to pass the dialup account information to pppd.
Anyway, for PPP clients, it's a lot more convenient just to use the
"user" and "password" options than messing around with the
{pap,chap}-secrets files. Since the "password" option is already
implemented, it ought to be documented along with the rest of the pppd
options.
-- Ian Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
