<HTML>
<HEAD>
<TITLE>Linux PPP FAQ: Process termination</TITLE>
</HEAD>
<BODY>
<A HREF="PPP-FAQ-8.html">Previous</A>
<A HREF="PPP-FAQ-10.html">Next</A>
<A HREF="PPP-FAQ.html#toc9">Table of Contents</A>
<HR>
<H2><A NAME="s9">9. Process termination</A></H2>



<H2><A NAME="ss9.1">9.1 Is there a \dip -k\ for PPP?</A></H2>

<P>No. There is no \<EM>dip -k</EM>\.</P>
<P>However, if you run dip -k, and have properly built
the dip process so that it knows that the lock file directory
is /var/locks, then you may use the command to terminate the pppd
process. The reason that this works is that dip will terminate
any process which owns the tty device, not just the one which
it started. This may be a security concern for some (perhaps many)
people. However, it is just the way that the program works. If
you are concerned about dip doing this action then either secure
dip so that it is executable by only specific people or remove
it from your system and use slattach, route, ifconfig, and arp
to do the dial-in functions of SLIP.</P>
<P>In the chat directory, there is a \<EM>PPP-off</EM>\
script. This will stop the PPP link in the same manner as the
\<EM>dip -k\</EM>.</P>
<P>I have included it below. (Cut it out. Store it in its own file.</P>
<P>Make the file executable with chmod.)</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
#!/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 `head -1 /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 [ ! &quot;$?&quot; = &quot;0&quot; ]; then
                rm -f /var/run/$DEVICE.pid
                echo &quot;ERROR: Removed stale pid file&quot;
                exit 1
        fi
#
# Success. Let pppd clean up its own junk.
        echo &quot;PPP link to $DEVICE terminated.&quot;
        exit 0
fi
#
# The PPP process is not running for ppp0
echo &quot;ERROR: PPP link is not active on $DEVICE&quot;
exit 1
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>In addition, you may still use \dip -k\ to terminate the
pppd link. The reason is that dip does not care if it started the
program which is using the serial device. It sends a SIGTERM to any
process which owns the serial device. (This is not a great idea,
however, that is the way that dip works.)</P>


<H2><A NAME="ss9.2">9.2 PPP does not hangup the modem when it terminates</A></H2>

<P>There are several reasons for this.
<UL>
<LI>Did you use the pppd \<EM>modem</EM>\ parameter? This parameter
controls whether or not the <EM>pppd</EM> process is to control
and honor the signals reflecting the modem status. This parameter
is explained in the man page for <EM>pppd</EM>.</LI>
<LI>Do you have the modem presenting the DCD signal and honoring
DTR? The Hayes sequence for this is usually \&amp;C1\.
If you reset the modem during the connection sequence with \ATZ\
then ensure that your modem is configured correctly.</LI>
<LI>The DTR signal is generated by the computer and instructs
the modem to disconnect. Hayes sequence for this is usually \&amp;D1\
or \&amp;D2\ with \&amp;D2\ being the preferred
setting for PPP. Many manufacturers will ignore the DTR condition
in their \factory defaults\ setting.</LI>
<LI>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.</LI>
<LI>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.
<P>The \shell\ script should have a format similar to the following:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
#!/bin/sh
exec pppd -detach modem ...
</PRE>
</CODE></BLOCKQUOTE>
</P>

</LI>
<LI>The use of <B>dip</B> and <B>diald</B> 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.
<P>[Ed: Sorry for the technical terminology. \in-band\
refers to the use of the protocol itself to detect a condition. It is
similar to using XON and XOFF as flow control characters. These
characters are sent along with the data and perform the flow control
operations. The \in-band\ is the opposite of
\out-of-band\. They both refer to \band\ as being
short for \bandwidth\. When something is
\in-band\, it is within the bandwidth of the signals. That
is, it takes some of the bandwidth to perform the additional
function. \out-of-band\ would be the equivalent of using the
RTS and CTS signal lines to do flow control. These do not take a
character. These are not sent with the data. The signals are just
additional lines that happen to do the required function.]</P>

</LI>
</UL>
</P>

<HR>
<A HREF="PPP-FAQ-8.html">Previous</A>
<A HREF="PPP-FAQ-10.html">Next</A>
<A HREF="PPP-FAQ.html#toc9">Table of Contents</A>
</BODY>
</HTML>
