9. Process termination

9.1 Is there a `dip -k' for PPP?

No. There is no `dip -k'.

In the chat directory, there is a `PPP-off' script. This will stop the PPP link in the same manner as the 'dip -k'.

I have included it below. (Cut it out. Store it in its own file. Make the file executable with chmod.)

#!/bin/sh
DEVICE=ppp0
#
# If the ppp0 pid file is present then the program is running. Stop it.
if [ -r /var/run/$DEVICE.pid ]; then
        kill -INT `cat /var/run/$DEVICE.pid`
#
# If the kill did not work then there is no process running for this
# pid. It may also mean that the lock file will be left. You may wish
# to delete the lock file at the same time.
        if [ ! "$?" = "0" ]; then
                rm -f /var/run/$DEVICE.pid
                echo "ERROR: Removed stale pid file"
                exit 1
        fi
#
# Success. Let pppd clean up its own junk.
        echo "PPP link to $DEVICE terminated."
        exit 0
fi
#
# The PPP process is not running for ppp0
echo "ERROR: PPP link is not active on $DEVICE"
exit 1

9.2 PPP does not hangup the modem when it terminates

There are several reasons for this.

• Did you use the pppd `modem' parameter? This parameter controls whether or not the pppd process is to control and honor the signals reflecting the modem status. This parameter is explained in the man page for pppd.
• Do you have the modem presenting the DCD signal and honoring DTR? The Hayes sequence for this is usually "&C1". If you reset the modem during the connection sequence with "ATZ" then ensure that your modem is configured correctly.

  The DTR signal is generated by the computer and instructs the modem to disconnect. Hayes sequence for this is usually "&D1" or "&D2" with "&D2" being the preferred setting for PPP. Many manufacturers will ignore the DTR condition in their `factory defaults' setting.

• Did you use a cheap cable which does not pass the DCD signal? Macintosh `Classic' cables are notorious for this problem. The Macintosh Classic does not use this signal.
• For dial-in connections, did you exec the pppd process properly? The pppd process should be `exec'ed from the script rather than simply executed. If you attempt to simply run the pppd process then it will be the shell which will receive the SIGHUP hangup signal and not the pppd process.

  The `shell' script should have a format similar to the following:

  ---

  #!/bin/sh
  exec pppd -detach modem ...
  

  ---

• The use of dip and diald has, on occasion, interfered with the ability of pppd to sense the loss of the carrier. In this case, you should use the lcp-echo-request and lcp-echo-failure options to detect the loss of the connection in-band.