ppp.sgml

eCos/RedBoot for勤研ARM AnywhereII(4510) 含全部源代码

<programlisting width=72>

$ ecosconfig add ppp

</programlisting>

<para>
In addition to the PPP package you will also need to have the
<literal>"Network"</literal> package and the <literal>"Serial Device
Drivers"</literal> package in the configuration. The dependencies and
requirements of the networking package are such that it is strongly
recommended that you start with the <literal>net</literal> template.
</para>

<para>
See the <productname>eCos</productname> User Guide for full details on
how to configure and build <productname>eCos</productname>.
</para>

</sect1>


<sect1 id="ppp-config-config">
<title>Configuring PPP</title>
<para>
The PPP package contains a number of configuration options that may be
changed to affect its behaviour.

<variablelist>

<varlistentry>
  <term>CYGNUM_PPP_PPPD_THREAD_PRIORITY</term>
  <listitem>
    <para>
    The PPP system contains two threads, One is used for receiving
    data from the link and processing control packets.  The other is
    used to transmit data asynchronously to the link when it cannot be
    completed synchronously. The receive thread runs at the priority
    given here, and the transmit thread runs at the next lower
    priority.  The exact priority needed here depends on the
    importance of the PPP subsystem relative to the rest of the
    system. The default is to put it in the middle of the priority
    range to provide reasonable response without impacting genuine
    high priority threads.
    </para>
    <para>
    Default value: <literal>CYGNUM_KERNEL_SCHED_PRIORITIES/2</literal>
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGPKG_PPP_DEBUG_WARN_ONLY</term>
  <listitem>
    <para>
    The runtime <varname>debug</varname> option enables logging of
    high level debug messages. Too many of these can interfere with
    the PPP device and may result in missed messages.  This is because
    these messages are emitted via the diag_printf() mechanism, which
    disables interrupts while it prints.  By default, therefore, we
    only report errors and warnings, and not all events. Setting this
    option to zero will enable the logging of all events.
    </para>
    <para>
    Default value: <literal>1</literal>
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGPKG_PPP_AUTH_DEFAULT_USER</term>
  <listitem>
    <para>
    This option gives the default value for the user name used to
    initialize the <structfield>user</structfield> field in the PPP
    options.
    </para>
    <para>
    Default value: <literal>"eCos"</literal>
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGPKG_PPP_AUTH_DEFAULT_PASSWD</term>
  <listitem>
    <para>
    This option gives the default value for the password used to
    initialize the <structfield>passwd</structfield> field in the PPP
    options.
    </para>
    <para>
    Default value: <literal>"secret"</literal>
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGPKG_PPP_DEFAULT_DIALUP_NUMBER</term>
  <listitem>
    <para>
    This option provides a default dialup number for use in
    <command>chat</command> scripts. This value is not used anywhere
    in the PPP package, but is provided to complete the information
    needed, alongside the user name and password, for accessing a
    typical dialup server.
    </para>
    <para>
    Default value: <literal>"5551234"</literal>
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGPKG_PPP_PAP</term>
  <listitem>
    <para>
    This component enables the inclusion of PAP authentication
    support.
    </para>
    <para>
    Default value: 1
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGPKG_PPP_CHAP</term>
  <listitem>
    <para>
    This component enables the inclusion of CHAT authentication
    support.
    </para>
    <para>
    Default value: 1
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGPKG_PPP_COMPRESSION</term>
  <listitem>
    <para>
    This component provides control over PPP compression
    features. WARNING: at present there are problems with this option,
    and and in any case the compression code needs to allocate large
    amounts of memory. Hence this option is currently disabled and
    should remain so.
    </para>
    <para>
    Default value: 0
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>PPP_BSDCOMP</term>
  <listitem>
    <para>
    This option enables inclusion of BSD compression into the PPP
    protocol.
    </para>
    <para>
    Default value: 0
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>PPP_DEFLATE</term>
  <listitem>
    <para>
    This option enables inclusion of ZLIB compression into the PPP
    protocol.
    </para>
    <para>
    Default value: 0
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGPKG_PPP_CHAT</term>
  <listitem>
    <para>
    This component enables the inclusion of a simple scripting system
    to bring up PPP connections.  It implements a subset of the
    <command>chat</command> scripting language.
    </para>
    <para>
    Default value: 1
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGNUM_PPP_CHAT_ABORTS_MAX</term>
  <listitem>
    <para>
    This option defines the maximum number of <literal>ABORT</literal>
    strings that the CHAT system will store.
    </para>
    <para>
    Default value: 10
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGNUM_PPP_CHAT_ABORTS_SIZE</term>
  <listitem>
    <para>
    This option defines the maximum size of each
    <literal>ABORT</literal> strings that the <command>chat</command>
    system will store.
    </para>
    <para>
    Default value: 20
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGNUM_PPP_CHAT_STRING_LENGTH</term>
  <listitem>
    <para>
    This option defines the maximum size of any expect or reply
    strings that the <command>chat</command> system will be given.
    </para>
    <para>
    Default value: 256
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGPKG_PPP_TEST_DEVICE</term>
  <listitem>
    <para>
    This option defines the serial device to be used for PPP test
    programs.
    </para>
    <para>
    Default value: <literal>"/dev/ser0"</literal>
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGPKG_PPP_TESTS_AUTOMATE</term>
  <listitem>
    <para>
    This option enables automated testing features in certain test
    programs. These programs will interact with a test server at the
    remote end of the serial link to run a variety of tests in
    different conditions. Without this option most tests default to
    running a single test instance and are suitable for being run by
    hand for debugging purposes.
    </para>
    <para>
    Default value: 0
    </para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>CYGDAT_PPP_TEST_BAUD_RATES</term>
  <listitem>
    <para>
    This option supplies a list of baud rates at which certain tests
    will run if the <literal>CYGPKG_PPP_TESTS_AUTOMATE</literal>
    option is set.
    </para>
    <para>
    Default value: <literal>"CYGNUM_SERIAL_BAUD_19200,CYGNUM_SERIAL_BAUD_38400,CYGNUM_SERIAL_BAUD_57600,CYGNUM_SERIAL_BAUD_115200"</literal>
    </para>
  </listitem>
</varlistentry>

</variablelist>


</para>

</sect1>


</chapter>

<!-- }}} -->
<!-- {{{ Chat                             -->

<chapter id="ppp-chat">
<title>CHAT Scripts</title>
<para>
The automated conversational scripting supported by the
<productname>eCos</productname> PPP package is a subset of the
scripting language provided by the <command>chat</command> command
found on most UNIX and Linux systems.
</para>

<para>
Unlike the <command>chat</command> command, the
<productname>eCos</productname> <function>cyg_ppp_chat()</function>
function takes as a parameter a zero-terminated array of pointers to
strings. In most programs this will be defined by means of an
initializer for a static array, although there is nothing to stop the
application constructing it at runtime. A simple script would be
defined like this:
</para>

<programlisting width=72>

static char *chat_script[] =
{
    "ABORT"        ,  "BUSY"        ,
    "ABORT"        ,  "NO CARRIER"  ,
    ""             ,  "ATD5551234"  ,
    "ogin:--ogin:" ,  "ppp"         ,
    "ssword:"      ,  "hithere"     ,
    0
};

</programlisting>

<para>
The following sections have been abstracted from the public domain
documentation for the <command>chat</command> command. 
</para>


<sect1 id="ppp-chat-script">
<title>Chat Script</title>
<para>
       A script consists of one or more "expect-send" pairs of
       strings, separated by spaces, with an optional "subexpect-
       subsend" string pair, separated by a dash as in the following
       example:
</para>

<programlisting width=72>

    "ogin:--ogin:"     ,  "ppp"       ,
    "ssword:"          ,   "hello2u2" ,
    0

</programlisting>

<para>
       This script fragment indicates that the
       <function>cyg_ppp_chat()</function> function should expect the
       string "ogin:". If it fails to receive a login prompt within
       the time interval allotted, it is to send a carriage return
       to the remote and then expect the string "ogin:" again.  If
       the first "ogin:" is received then the carriage return is not
       generated.
</para>
<para>
       Once it received the login prompt the
       <function>cyg_ppp_chat()</function> function will send the
       string "ppp" and then expect the prompt "ssword:".  When it
       receives the prompt for the password, it will send the password
       "hello2u2".
</para>
<para>
       A carriage return is normally sent following the reply string.
       It is not expected in the "expect" string unless it is
       specifically requested by using the "\r" character sequence.
</para>
<para>
       The expect sequence should contain only what is needed to
       identify the string. It should not contain variable
       information. It is generally not acceptable to look for time
       strings, network identification strings, or other variable
       pieces of data as an expect string.
</para>
<para>
       To help correct for characters which may be corrupted during
       the initial sequence, look for the string "ogin:" rather than
       "login:". It is possible that the leading "l" character may be
       received in error and you may never find the string even though
       it was sent by the system. For this reason, scripts look for
       "ogin:" rather than "login:" and "ssword:" rather than
       "password:".
</para>
<para>
       A very simple script might look like this:
</para>
<programlisting width=72>

    "ogin:"    , "ppp"       ,
    "ssword:"  , " hello2u2" ,
    0

</programlisting>

<para>
       In other words, expect "....ogin:", send "ppp", expect "...ssword:",
       send "hello2u2".
</para>
<para>
       In actual practice, simple scripts are rare. At the very least,
       you should include sub-expect sequences should the original
       string not be received. For example, consider the following
       script:
</para>
<programlisting width=72>

    "ogin:--ogin:"  , "ppp"     ,
    "ssword:"       , "hello2u2",
    0

</programlisting>
<para>
       This would be a better script than the simple one used earlier.
       This would look for the same "login:" prompt, however, if one
       was not received, a single return sequence is sent and then it
       will look for "login:" again. Should line noise obscure the
       first login prompt then sending the empty line will usually
       generate a login prompt again.
</para>

</sect1>

<sect1 id="ppp-chat-abort">
<title>ABORT Strings</title>

<para>
       Many modems will report the status of the call as a
       string. These strings may be CONNECTED or NO CARRIER or
       BUSY. It is often desirable to terminate the script should the
       modem fail to connect to the remote. The difficulty is that a
       script would not know exactly which modem string it may
       receive. On one attempt, it may receive BUSY while the next
       time it may receive NO CARRIER.
</para>
<para>
       These "abort" strings may be specified in the script using
       the ABORT sequence. It is written in the script as in  the
       following example:
</para>
<programlisting width=72>

    "ABORT"    , "BUSY"    ,
    "ABORT"    , "NO CARRIER"  ,
    ""         , "ATZ"         ,
    "OK"       , "ATDT5551212" ,
    "CONNECT"  , ...

</programlisting>

<para>
       This sequence will expect nothing; and then send the string
       ATZ.  The expected response to this is the string OK. When it
       receives OK, it sends the string ATDT5551212 to dial the
       telephone.  The expected string is CONNECT. If the string
       CONNECT is received the remainder of the script is
       executed. However, should the modem find a busy telephone, it
       will send the string BUSY. This will cause the string to match
       the abort character sequence. The script will then fail because
       it found a match to the abort string. If it received the string
       NO CARRIER, it will abort for the same reason. Either string
       may be received. Either string will terminate the chat script.