"The Linux Gazette...making Linux just a little more fun!"

PPP Disconnects

From sipior on Tue, 05 Jan 1999

Greetings, Mr. Dennis!

Having taken my computer home with me for a couple of weeks, so that

I might not be Quake-deprived for the Christmas season, I found myself setting up a PPP connection with a local ISP. I was able to manually effect a PPP connection with little difficulty at all---however, I have been unable to automate the dialup process with ppp-on and ppp-on-dialer scripts (as detailed in the PPP-HOWTO). After tailoring these scripts to my particular setup, I was able to connect well enough, only to have the modem automatically hang up immediately! The relevant portion of my system log (sanitised for our mutual protection follows:

Jan  2 18:17:56 sarnath kernel: PPP: version 2.2.0 (dynamic channel
allocation)
Jan  2 18:17:56 sarnath kernel: PPP Dynamic channel allocation code
copyright 1995 Caldera, Inc.
Jan  2 18:17:56 sarnath kernel: PPP line discipline registered.
Jan  2 18:17:56 sarnath kernel: Serial driver version 4.13 with no serial options enabled
Jan  2 18:17:56 sarnath kernel: tty00 at 0x03f8 (irq = 4) is a 16550A
Jan  2 18:17:56 sarnath kernel: tty01 at 0x02f8 (irq = 3) is a 16550A
Jan  2 18:17:56 sarnath kernel: registered device ppp0
Jan  2 18:17:56 sarnath pppd[599]: pppd 2.3.3 started by root, uid 0
Jan  2 18:17:57 sarnath chat[604]: timeout set to 3 seconds

This timeout might be a tad shorter than you'd like. Try 15 seconds or so.

Jan  2 18:17:57 sarnath chat[604]: ATH0^M^M
Jan  2 18:17:57 sarnath chat[604]: OK
Jan  2 18:17:57 sarnath chat[604]:  -- got it
Jan  2 18:17:57 sarnath chat[604]: send (ATDTXXXXXXX^M)
Jan  2 18:17:58 sarnath chat[604]: expect (CONNECT)
Jan  2 18:17:58 sarnath chat[604]: ^M
Jan  2 18:18:16 sarnath chat[604]: ATDTXXXXXXX^M^M

... your forgot to sanitize your local number from these logs. I've done it here.

Jan  2 18:18:16 sarnath chat[604]: CONNECT
Jan  2 18:18:16 sarnath chat[604]:  -- got it
Jan  2 18:18:16 sarnath chat[604]: send (^M)
Jan  2 18:18:16 sarnath chat[604]: expect (ost :) 
Jan  2 18:18:16 sarnath chat[604]:  38400^M
Jan  2 18:18:18 sarnath chat[604]: - Blue Moon K56flex -^M
Jan  2 18:18:18 sarnath chat[604]: ^M
Jan  2 18:18:18 sarnath chat[604]: Select HOST:^M
Jan  2 18:18:18 sarnath chat[604]: ^M
Jan  2 18:18:18 sarnath chat[604]: ppp^M
Jan  2 18:18:18 sarnath chat[604]: shell^M
Jan  2 18:18:18 sarnath chat[604]: bbs^M
Jan  2 18:18:18 sarnath chat[604]: ^M
Jan  2 18:18:18 sarnath chat[604]: Type new to register for net access.^M
Jan  2 18:18:18 sarnath chat[604]: ^M
Jan  2 18:18:18 sarnath chat[604]: host:
Jan  2 18:18:18 sarnath chat[604]:  -- got it
Jan  2 18:18:18 sarnath chat[604]: send (ppp^M)
Jan  2 18:18:18 sarnath chat[604]: expect (ogin :) 
Jan  2 18:18:18 sarnath chat[604]:  ^M
Jan  2 18:18:18 sarnath chat[604]: host: ppp^M
Jan  2 18:18:18 sarnath chat[604]: login:
Jan  2 18:18:18 sarnath chat[604]:  -- got it
Jan  2 18:18:18 sarnath chat[604]: send (xxxxxxx^M)
Jan  2 18:18:18 sarnath chat[604]: expect (assword :) 
Jan  2 18:18:18 sarnath chat[604]:  xxxxxxx^M
Jan  2 18:18:18 sarnath chat[604]: Password:
Jan  2 18:18:18 sarnath chat[604]:  -- got it
Jan  2 18:18:18 sarnath chat[604]: send (********^M)
Jan  2 18:18:18 sarnath pppd[599]: Serial connection established.
Jan  2 18:18:19 sarnath pppd[599]: Using interface ppp0
Jan  2 18:18:19 sarnath pppd[599]: Connect: ppp0 <--> /dev/ttyS1
Jan  2 18:18:23 sarnath pppd[599]: Modem hangup
Jan  2 18:18:23 sarnath pppd[599]: Connection terminated.
Jan  2 18:18:24 sarnath pppd[599]: Exit.
Jan  2 18:19:56 sarnath kernel: PPP: ppp line discipline successfully unregistered

Sorry for the long excerpt, by the way---if I had a better idea of where the trouble was, I could perhaps have quoted fewer lines...

What I find perplexing is that the modem hangup comes directly after

the connection is established, but with no IP number yet assigned. I have also attached my /etc/ppp/options, /etc/ppp/scripts/ppp-on, and /etc/ppp/scripts/ppp-on-dialer files. These all come with the RedHat 5.0 distribution, obviously edited for my circumstances.

Ultimately, I guess my question is: "What am I missing?" Connecting manually is not exactly a Brobdingnagian task, but it does keep me from using diald, along with some other clever script-driven ppp utilities. I have been up and down the PPP-HOWTO, along with other /usr/doc/ppp files, and cannot effect a solution. I assume what I am missing is terribly obvious, and maybe a fresh pair of eyes can see after a few minutes what mine cannot after many hours If there is any more information you require, I will be happy to provide it, though I have tried to be as painfully complete as possible in this e-mail.

Anyway, I thank you for any time you can spare on this problem, and I look forward to hearing from you!

Regards, Michael Sipior

Finger [email protected] for Public PGP Key
DSS -- C1FE AB1E CDE4 0E55 6A7D BE58 0058 E502 A645 5531

debug
-detach
/dev/ttyS1
38400
modem
lock
crtscts
defaultroute
asyncmap 0
mtu 552
mru 552

Try it with the -detach directive commented out.

#!/bin/sh
#
# Script to initiate a ppp connection. This is the first part of the
# pair of scripts. This is not a secure pair of scripts as the codes
# are visible with the 'ps' command.  However, it is simple.
#
# These are the parameters. Change as needed.
TELEPHONE=*******	# The telephone number for the connection
ACCOUNT=msipior	# The account name for logon (as in 'George Burns')
PASSWORD=********	# The password for this account (and 'Gracie Allen')
LOCAL_IP=0.0.0.0	# Local IP address if known. Dynamic = 0.0.0.0
REMOTE_IP=0.0.0.0	# Remote IP address if desired. Normally 0.0.0.0
NETMASK=255.255.255.0	# The proper netmask if needed
#
# Export them so that they will be available at 'ppp-on-dialer' time.
export TELEPHONE ACCOUNT PASSWORD
#
# This is the location of the script which dials the phone and logs
# in.  Please use the absolute file name as the $PATH variable is not
# used on the connect option.  (To do so on a 'root' account would be
# a security hole so don't ask.)
#
DIALER_SCRIPT=/etc/ppp/scripts/ppp-on-dialer
#
# Initiate the connection
#
# I put most of the common options on this command. Please, don't
# forget the 'lock' option or some programs such as mgetty will not
# work. The asyncmap and escape will permit the PPP link to work with
# a telnet or rlogin connection. You are welcome to make any changes
# as desired. Don't use the 'defaultroute' option if you currently
# have a default route to an ethernet gateway.
#
exec /usr/sbin/pppd debug lock modem crtscts /dev/ttyS1 38400 \

asyncmap 20A0000 escape FF kdebug 0 $LOCAL_IP:$REMOTE_IP noipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT

Some of these options conflict with those your list from /etc/ppp/options file above. In particular I notice that the asyncmap is different. I also note that the MTU/MRU values you have listed are a bit odd. I usually see 296 for slower modems (14.4 and under) and 576 for faster modems (28.8 and up). The 'kdebug' option here results in those kernel/syslog messages from pppd (and the -v on your chat script, below, results in the syslog messages from that command).

Try it with an empty /etc/ppp/options file (that file is global and might conflict with the directives that you're putting on the command line). Try removing all of these options from the pppd invocation --- and isolating them into their own options file. Replace all the options on this long command line with just:

/usr/sbin/pppd file /etc/ppp/foo.options

... and put each option directive (and it's arguments) on a single line in the foo.options file.

#!/bin/sh
#
# This is part 2 of the ppp-on script. It will perform the connection
# protocol for the desired connection.
#
exec /usr/sbin/chat -v				\

TIMEOUT		3				ABORT		'\nBUSY\r'			ABORT		'\nNO ANSWER\r'			ABORT		'\nRINGING\r\n\r\nRINGING\r'	"		'\rAT'				'OK-+++\c-OK'	ATH0				TIMEOUT		30				OK		ATDT$TELEPHONE			CONNECT		"				ost:		ppp				ogin:--ogin:	$ACCOUNT			assword:	$PASSWORD

This seems like an odd way to do this. I usually isolate my chat scripts in their own file and use my ppp/options file's 'connect' directive to invoke 'chat' with the -f option --- which points to my standalone chat script like so:

connect /usr/sbin/chat -v -f /etc/ppp/MYISP.chat

... with different files for different chat scripts. I also invoke 'pppd' with just the 'file' directive on its command line --- like:

/usr/sbin/pppd file /etc/ppp/MYISP.options

... and localize my options therein. My global options file then just has the "lock" directive --- or is blank (for some special cases).

I really don't see anything that jumps out at me. However, I've noted a couple of oddities. One other suggestion which relates to a similar problem I had once:

When you log in interactively, look for the last bit of plain text that's printed by your ISPs system before it starts printing the PPP "gibberish"

One of the ISPs I worked with would print "starting PPP..." after my script would enter the password. This was getting "stuck" in a buffer somewhere and confusing pppd (similar to what happens in C when you use a '' library call with a bad format specifier). The problem only showed up when I was using the chat script and not if I used 'minicom' to start the session, then quit out of that while leaving the connection up and using pppd to take over the existing connection.

Adding a last "expect" string to my chat script to "gobble that last text message up" seemed to solve the problem.

Try that and see if it helps. Then ask your ISP for some additional tips.

You might also try one or several of the GUI PPP configuration frontends. I've never used any of them --- but they've apparently gotten pretty good for the common cases. Any of the good ones should generate text chat script and options files that you can manually tweak.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 37 February 1999

				1	2	3	4	5	6	7	8	9	10
				11	12	14	15	16	17	18	19	21	22
				23	28	29	30	31	32	33	34	37	38
39	41	42	43	44	45	46	47	48	49