ppp.sgml

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

</para>

</sect1>

<sect1 id="ppp-chat-timeout">
<title>TIMEOUT</title>
<para>
       The initial timeout value  is  45  seconds.
       To  change  the  timeout value for the next expect string,
       the following example may be used:
</para>
<programlisting width=72>

    ""              , "ATZ"         ,
    "OK"            , "ATDT5551212" ,
    "CONNECT"       , "\\c"         ,
    "TIMEOUT"       , "10"          ,
    "ogin:--ogin:"  , "ppp"         ,
    "TIMEOUT"       , "5"           ,
    "assword:"      , "hello2u2"    ,
    0

</programlisting>
<para>
       This will change the timeout to 10 seconds when it expects the
       login: prompt. The timeout is then changed to 5 seconds when
       it looks for the password prompt.
</para>
<para>
       The  timeout,  once changed, remains in effect until it is
       changed again.
</para>

</sect1>

<sect1 id="ppp-chat-eot">
<title>Sending EOT</title>
<para>
       The special reply string of EOT indicates  that  the  chat
       program  should  send an EOT character to the remote. This
       is normally the End-of-file character sequence.  A  return
       character is not sent following the EOT.  The EOT sequence
       may be embedded into the send string  using  the  sequence
       "\x04" (i.e. a Control-D character).
</para>
</sect1>

<sect1 id="ppp-chat-escape">
<title>Escape Sequences</title>
<para>
Most standard <command>chat</command> escape sequences can be replaced
with standard C string escapes such as '\r', '\n', '\t'
etc. Additional escape sequences may be embedded in the expect or
reply strings by introducing them with <emphasis>two</emphasis>
backslashes.
</para>

<variablelist>

<varlistentry>
<term>\\c</term>
<listitem>
<para>
Suppresses the newline at the end of the reply string.  This is the
only method to send a string without a trailing return character. It
must be at the end of the send string.  For example, the sequence
"hello\\c" will simply send the characters h, e, l, l, o.  (not valid
in expect strings.)
</para>
</listitem>
</varlistentry>

</variablelist>

</sect1>

</chapter>

<!-- }}} -->
<!-- {{{ Drivers                          -->

<chapter id="ppp-drivers">
<title>PPP Enabled Device Drivers</title>
<para>
For PPP to function fully over a serial device, its driver must
implement certain features. At present not all
<productname>eCos</productname> serial drivers implement these
features. A driver indicates that it supports a certain feature by
including an <literal>"implements"</literal> line in its CDL for the
following interfaces:
</para>

<variablelist>

<varlistentry>
<term><literal>CYGINT_IO_SERIAL_FLOW_CONTROL_HW</literal></term>
<listitem>
<para>
This interface indicates that the driver implements hardware flow
control using the RTS and CTS lines. When data is being transferred
over high speed data lines, it is essential that flow control be used
to prevent buffer overrun.
</para>
<para>
The PPP subsystem functions best with hardware flow control. If this
is not available, then it can be configured to use software flow
control. Since software flow control is implemented by the device
independent part of the serial device infrastructure, it is available
for all serial devices. However, this will have an effect on the
performance and reliability of the PPP link.
</para>
</listitem>
</varlistentry>


<varlistentry>
<term><literal>CYGINT_IO_SERIAL_LINE_STATUS_HW</literal></term>
<listitem>
<para>
This interface indicates that the driver implements a callback
interface for indicating the status of various RS232 control lines. Of
particular interest here is the ability to detect changes in the
Carrier Detect (CD) line. Not all drivers that implement this
interface can indicate CD status.
</para>
<para>
This functionality is only needed if it is important that the link be
dropped immediately a telephone connection fails. Without it, a
connection will only be dropped after it times out. This may be
acceptable in many situations.
</para>
</listitem>
</varlistentry>

</variablelist>

<para>
At the time of writing, the serial device drivers for the following
platforms implement some or all of the required functionality:
</para>

<itemizedlist>

<listitem>
<para>
All drivers that use the generic 16x5x driver implement all functions:
</para>
<itemizedlist>
<listitem><para>ARM CerfPDA</para></listitem>
<listitem><para>ARM IQ80321</para></listitem>
<listitem><para>ARM PID</para></listitem>
<listitem><para>ARM IOP310</para></listitem>
<listitem><para>i386 PC</para></listitem>
<listitem><para>MIPS Atlas</para></listitem>
<listitem><para>MIPS Ref4955</para></listitem>
<listitem><para>SH3 SE77x9</para></listitem>
</itemizedlist>
</listitem>

<listitem>
<para>
The following drivers implement flow control but either do not support
line status callbacks, or do not report CD changes:
</para>
<itemizedlist>
<listitem><para>SH4 SCIF</para></listitem>
<listitem><para>A&amp;M AdderI</para></listitem>
<listitem><para>A&amp;M AdderII</para></listitem>
</itemizedlist>
</listitem>

<listitem>
<para>
All other drivers can support software flow control only.
</para>
</listitem>

</itemizedlist>


</chapter>

<!-- }}} -->
<!-- {{{ Tests                            -->

<chapter id="ppp-tests">
<title>Testing</title>


<sect1>
<title>Test Programs</title>

<para>
There are a number of test programs supplied with the PPP
subsystem. By default all of these tests use the device configured by
<literal>CYGPKG_PPP_TEST_DEVICE</literal> as the PPP link device.
</para>

<variablelist>

<varlistentry>
<term><literal>ppp_up</literal></term>
<listitem>
<para>
This test just brings up the PPP link on
<literal>CYGPKG_PPP_TEST_DEVICE</literal> and waits until the remote end brings
it back down. No modem lines are used and the program expects a PPP
connection to be waiting on the other end of the line. Typically the
remote end will test the link using <command>ping</command> or access
the HTTP system monitor if it is present.
</para>
<para>
If <literal>CYGPKG_PPP_TESTS_AUTOMATE</literal> is set, then this test
attempts to bring PPP up at each of the baud rates specified in
<literal>CYGDAT_PPP_TEST_BAUD_RATES</literal>. If it is not set then
it will just bring the connection up at 115200 baud.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>ppp_updown</literal></term>
<listitem>
<para>
This test brings the PPP link up on
<literal>CYGPKG_PPP_TEST_DEVICE</literal> and attempts to
<command>ping</command> the remote end of the link. Once the pings
have finished, the link is then brought down.
</para>
<para>
If <literal>CYGPKG_PPP_TESTS_AUTOMATE</literal> is set, then this test
attempts to bring PPP up at each of the baud rates specified in
<literal>CYGDAT_PPP_TEST_BAUD_RATES</literal>. If it is not set then
it will just bring the connection up at 115200 baud.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>chat</literal></term>
<listitem>
<para>
This test does not bring the PPP link up but simply executes a chat
script. It expects a server at the remote end of the link to supply
the correct responses.
</para>
<para>
This program expects the <command>test_server.sh</command> script to
be running on the remote end and attempts several different tests,
expecting a variety of different responses for each.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>ppp_auth</literal></term>
<listitem>
<para>
This test attempts to bring up the PPP link under a variety of
different authentication conditions. This includes checking that both
PAP and CHAP authentication work, and that the connection is rejected
when the incorrect authentication protcol or secrets are used. 
</para>
<para>
This test expects the <command>test_server.sh</command> script to be
running on the remote end. For this test to work the <filename>/etc/ppp/pap-secrets</filename> file on the remote
end should contain the following two lines:
</para>
<programlisting width=72>
eCos       *         secret       *
eCosPAP    *         secretPAP    *
</programlisting>
<para>
The <filename>/etc/ppp/chap-secrets</filename> file should contain:
</para>
<programlisting width=72>
eCos       *         secret       *
eCosCHAP   *         secretCHAP   *
</programlisting>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>isp</literal></term>
<listitem>
<para>
This test expects the serial test device to be connected to a Hayes
compatible modem. The test dials the telephone number given in
<literal>CYGPKG_PPP_DEFAULT_DIALUP_NUMBER</literal> and attempts to
log on to an ISP using the user name and password supplied in
<literal>CYGPKG_PPP_AUTH_DEFAULT_USER</literal> and
<literal>CYGPKG_PPP_AUTH_DEFAULT_PASSWD</literal>. Once the PPP
connection has been made, the program then attempts to ping a number
of well known addresses.
</para>
<para>
Since this test is designed to interact with an ISP, it does not run
within the automated testing system.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>tcp_echo</literal></term>
<listitem>
<para>
This is a version of the standard network <command>tcp_echo</command>
test that brings up the PPP connection before waiting for the
<command>tcp_sink</command> and <command>tcp_source</command> programs
to connect. It is expected that at least one of these programs will
connect via the PPP link. However, if another network interface is
present, such as an ethernet device, then one may connect via that
interface.
</para>
<para>
While this test is supported by the <command>test_server.sh</command>
script, it runs for such a long time that it should not normally be
used during automated testing.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>nc_test_slave</literal></term>
<listitem>
<para>
This is a version of the standard network
<command>nc_test_slave</command> test that brings up the PPP
connection before waiting for the <command>nc_test_master</command>
program to connect. It is expected that the master will connect via
the PPP link.
</para>
<para>
While this test is supported by the <command>test_server.sh</command>
script, it runs for such a long time that it should not normally be
used during automated testing.
</para>
</listitem>
</varlistentry>

</variablelist>

</sect1>

<sect1 id="ppp-test-script">
<title>Test Script</title>

<para>
The PPP package additionally contains a shell script
(<command>test_server.sh</command>) that may be used to operate the
remote end of a PPP test link.
</para>

<para>
The script may be invoked with the following arguments:
</para>

<variablelist>

<varlistentry>
<term><literal>--dev=&lt;devname&gt;</literal></term>
<listitem>
<para>
This mandatory option gives the name of the device to be used for the
PPP link. Typically <literal>"/dev/ttyS0"</literal> or
<literal>"/dev/ttyS1"</literal>.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>--myip=&lt;ipaddress&gt;</literal></term>
<listitem>
<para>
This mandatory option gives the IP address to be attached to this end
of the PPP link.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>--hisip=&lt;ipaddress&gt;</literal></term>
<listitem>
<para>
This mandatory option gives the IP address to be attached to the
remote (test target) end of the PPP link.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>--baud=&lt;baud_rate&gt;</literal></term>
<listitem>
<para>
This option gives the baud rate at which the PPP link is to be run. If
absent then the link will run at the value set for
<literal>--redboot-baud</literal>.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>--redboot</literal></term>
<listitem>
<para>
If this option is present then the script will look for a
<literal>"RedBoot&gt;"</literal> prompt between test runs. This is
necessary if the serial device being used for testing is also used by
RedBoot.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>--redboot-baud=&lt;baud_rate&gt;</literal></term>
<listitem>
<para>
This option gives the baud rate at which the search for the RedBoot
prompt will be made. If absent then the link will run at 38400 baud.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>--debug</literal></term>
<listitem>
<para>
If this option is present, then the script will print out some
additional debug messages while it runs.
</para>
</listitem>
</varlistentry>

</variablelist>

<para>
This script operates as follows: If the <literal>--redboot</literal>
option is set it sets the device baud rate to the RedBoot baud rate
and waits until a <literal>"RedBoot&gt;"</literal> prompt is encountered.
It then sets the baud rate to the value given by the
<literal>--baud</literal> option and reads lines from the device until
a recognizable test announce string is read. It then executes an
appropriate set of commands to satisfy the test. This usually means
bringing up the PPP link by running <command>pppd</command> and maybe
executing various commands. It then either terminates the link itself,
or waits for the target to terminate it. It then goes back to looking
for another test announce string. If a string of the form
<literal>"BAUD:XXX"</literal> is received then the baud rate is
changed depending on the <literal>XXX</literal> value. If a
<literal>"FINISH"</literal> string is received it returns to waiting
for a <literal>"RedBoot>"</literal> prompt. The script repeats this
process until it is terminated with a signal.
</para>

</sect1>

</chapter>

<!-- }}} -->


</part>