Date: Sat, 6 Jan 1996 13:49:14 -0500 From: blewis@vet.vet.purdue.edu To: FreeBSD-gnats-submit@freebsd.org Subject: misc/934: userland ppp chokes on long LOGIN scripts Message-ID: <199601061849.NAA08536@localhost> Resent-Message-ID: <199601061900.LAA09984@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 934
>Category: misc
>Synopsis: ppp dies with Bus Error when processing long LOGIN scripts
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Jan 6 11:00:01 PST 1996
>Last-Modified:
>Originator: Benjamin Lewis
>Organization:
>Release: FreeBSD 2.1-STABLE i386
>Environment:
ppp: $Id: main.c,v 1.11 1995/10/08 14:57:29 amurai Exp $
uname -a:
FreeBSD oddity.vet.purdue.edu 2.1.0-RELEASE FreeBSD 2.1.0-RELEASE #0: \
Mon Jan 1 17:58:49 EST 1996 \
blewis@oddity.vet.purdue.edu:/usr/src/sys/compile/YLANA i386
>Description:
In order to get an 8-bit clean line at our school, it is necessary
to jump through a few hoops with the annex boxes we call in to.
This means that a relatively long LOGIN script is required to get
a ppp connection working.
Although I use "SLiRP" on the remote end, I'm fairly confident
that it is not the cause of the problem, as I am able to get a
good connection using the "term" command in ppp.
In the attatched ppp.conf file, uncommenting the first "set login ..."
line does not produce a core dump (it also doesn't produce a clean
line, and therefore doesn't do the job). Using the second
"set login ..." line gets a clean line, but results in a Bus Error
right after the "login OK!" message is written.
Experiments with printf's in different locations lead me to believe
that the problem is occuring after "DialModem()" returns, but
before "DialCommand()" or "main()" get control back. I can put
any number of printf's before DialModem()'s return(1) that will be
printed, but nothing ever get executed after the "if (DialModem()) {"
line in either main() or DialCommand().
The "show modem" command reveals that the entire LOGIN string does
get read and stored, which was not the case before I shortened it
by abbreviating commands.
Also, ppp doesn't compile as-is with DEBUG defined, some minor
modifications are necessary. Once I got it compiled with DEBUG,
there were no further clues as to the cause of the error.
>How-To-Repeat:
Using the attatched or similar ppp.conf, "ppp -auto vet" or
"ppp vet <RETURN> dial <RETURN>".
An easier method might involve setting up your own login script
to issue a few random commands before eventually starting the
ppp connection.
>Fix:
Unknown. Perhaps provide a way to use the real "chat" command
to set up the connection, as that works fine in my case with pppd.
#/etc/ppp/ppp.conf
default:
set debug phase chat lcp ipcp
set device /dev/cuaa2
set speed 115200
disable pred1 lqr
deny pred1 lqr
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT"
vet:
set phone 4961440
# set login "TIMEOUT 5 e>-\\n-e> blewis > c\\svet n:-\\n-n: blewis d: mypass >> slirp"
# I have made the next login script as short as possible, and therefore have
# abbreviated all the commands as much as I can. What happens is that I
# sign onto the annex box, set an escape character, log in to "vet," issue
# the escape char ('X') to go back to the annex, set the session "passall,"
# return to "vet," and issue the "slirp" command.
set login "TIMEOUT 5 e>-\\n-e> blewis > set\\spo\\slo\\sX > c\\svet n:-\\n-n: blewis d: mypass >> X >-\\n-> set\\ssess\\spass > fg\\n\\n >> slirp"
set timeout 120
set ifaddr 10.0.2.15 128.210.79.50
add 0 255.255.255.0 128.210.79.50
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601061849.NAA08536>