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

# The Answer Guy

#### By James T. Dennis, linux-questions-only@ssc.com
Starshine Technical Services, http://www.starshine.org/

### 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 sipior@aloha.astro.psu.edu 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