Debugging SLIP and PPP Connections

Turning on Debugging

• For Irix SLIP and PPP: add '-d' options to the command. The more "d"s, the more debugging. Four "d"s is usually required for the first pass of testing. To check out the answering PPP, you must add "debug=4" (larger number for more debugging) to the line in /etc/ppp.conf, the debugging output goes to /usr/adm/SYSLOG.
• For MorningStar PPP, add "log - debug 2" (the "-" is to send debugging info to the terminal, use larger numbers for more debugging).

You are really interested in only a few key points in the debugging output. The debugging format is different for each program, so I will point out what to look for. First, make sure that the computer is really talking to the modem. One of the debugging lines displayed tells you which port the software is trying to use, which speed it is using, and what dialer script it is trying to use. These should match what you configured.

The usual problem at this point is a chat script error. Here is a sample successful login using Irix PPP to a Telebit NetBlazer (my comments are enclosed in braces "{}"):

# ppp -dddd -r slipserv
ppp slipserv: LCP initialized
ppp slipserv: IPCP initialized
conn(Pslipserv)                    {the name in the Systems file}
Device Type ACUSLIP wanted
Internal caller type 212
Use Port /dev/ttyf1, acu - /dev/null, Phone Number 5551212 {the tty}
/dev/null is open                  {#1 failure point}
filelock: ok
filelock: ok
dcf is 6
fixline(6, 38400)                  {note the speed}
ACU write ok(null)
fixline(6, 38400)
set interface 212
processdev: calling setdevcfg(, ACUSLIP)    {the Devices entry used}
gdial(zy1496) called               {the Dialers entry used}
expect: ("")                       {this is in the Dialers script}
got it
sendthem (DELAY
^MPAUSE
ATs2=128s0=0^M)
expect: (OK^M)                     {can it can talk to the modem?}
^MATs2=128s0=0^M^M^JOK^Mgot it     {Yep! #2 failure point}
sendthem (<NO CR>ATdtw5551212^M)   {dialing the phone number}
expect: (CONNECT)                  {waiting for the connect...}
^JATdtw5551212^M^M^JCONNECTgot it  {connected! #3 failure point}
getto ret 6 
expect: ("")                       {starting the chat script in Systems}
got it
sendthem (<NO CR>^M)
expect: (ogin:)
 38400/V32b 14400/V42b^M^J^M^J^M^JTelebit's NetBlazer {note the connect speed}
   Version 2.1^M^J^M^Jslipserv login:got it   {#4 failure point}
sendthem (Poniboshi^M)              {sending the login ID}
expect: (assword:)
 Poniboshi^M^JPassword:got it       {#5 failure point}
sendthem (??????????^M)             {I've protected my password}
expect: (enabled)
 ^M^J^M^JPacket mode enabledgot it  {#6 failure point}
                                    {now PPP negotiation starts}
  banner: ^M^J~^?}#@!}!} } }8}!}$}%\}"}&} } } } }%}&}3^EJ}6}'}"}(}"F^E~
ppp slipserv: saving 53 bytes to salvage
ppp slipserv: starting with /dev/ttyf1 debug=2 active_timeout=0 inactive=0
ppp slipserv: IPCP Initial (0)->Starting (1)
ppp slipserv: LCP Initial (0)->Closed (2)
ppp slipserv: LCP Closed (2)->Req-Sent (6)
ppp slipserv: LCP Req-Sent (6)->Ack-Sent (8)
ppp slipserv: LCP Ack-Sent (8)->Opened (9)
ppp slipserv: MTU=1500 MRU=1500 accm=0 pcomp=y acomp=y my-magic=0x7fb6508b his=0x13854a16
ppp slipserv: entering Authenticate phase
ppp slipserv: entering Network phase
ppp slipserv: IPCP Starting (1)->Req-Sent (6)
ppp slipserv: IPCP Req-Sent (6)->Ack-Sent (8)
ppp slipserv: IPCP Ack-Sent (8)->Opened (9)
ppp slipserv: 192.48.197.10 to 192.26.51.135
ppp slipserv: rx_vj_comp=y,tx=y rx_compslot=n,tx=n rx_slots=16,tx=15

                                        {now PPP is up and running}

Note: Details will vary between IRIX releases and patches, and depending on what server you are dialing into.

If you get a timeout at any point instead of going on to the next part, this should be a strong indication of which part of the configuration to go back and re-check. The following details are numbered to match the {#N failure point} in the listing above:

1. There are several possible error message right around this point, usually some variation on "error opening device" (permissions are wrong, or something else is using it, like /etc/getty) or "device locked" (another process is using the device: uugetty, cu, kermit, or another ppp is already running).
2. If you get a timeout here, you can't talk to the modem -- time to check the fundamentals again.
3. A timeout here indicates that either there is no modem at that phone number, the phone number is wrong (you might need to dial "9" first, etc), or it isn't setup to answer the phone. This is a server problem.
4. A timeout here indicates that the server isn't setup to allow logins. Possibly the uugetty isn't configured correctly. This is another problem on the server.
5. A timeout here means that you don't have a password on the server, or it is spelled differently. This is a configuration problem.
6. A timeout here indicates that your chat script in the /etc/uucp/Systems file is incorrect, waiting for the wrong thing. A debug level of 4 or more will show all the text sent by the server before PPP protocol starts. This may indicate that you have incorrect expect-send pairs in your chat script, or that your server requires different ones than you have supplied.

I hope and intend that this documentation can help you with your PPP connection problems. My other commitments (like work) permitting, I will attempt to help you on issues not covered, or that you are unclear on. Please make sure that you provide me a valid return email address! (I won't try to fix it).

Last modified: Wed Sep 13 14:59:54 1995