Tải bản đầy đủ
[Appendix A] A.3 chat

[Appendix A] A.3 chat

Tải bản đầy đủ

[Appendix A] A.3 chat

Runs the chat script in stderr verbose mode. The stderr verbose mode displays informational
messages on the stderr device. See Chapter 6 for an example of this being used with pppd.
-t timeout
Sets the maximum time to wait for an expected string. If the expected string is not received in
timeout seconds, the reply string is not sent and the script
terminates—unless an alternate send is defined. If defined, the alternate
send (more about this later) is sent and the remote system is given one more timeout period
to respond. If this fails, the script is terminated with a nonzero error code. By default, the
timeout period is 45 seconds.
-f scriptfile
Reads the chat script from the scriptfile instead of from the command line. Multiple
lines of expect/send pairs are permitted in the file.
-r reportfile
Writes the output generated by REPORT strings to the reportfile. By default, REPORT
strings are written to stderr. The REPORT keyword is covered below.
In order to make the scripts more useful and robust, chat provides special keywords, escape
sequences, and alternate send/expect pairs that can be used in the script. First let's look at the five chat
keywords.
Two keywords transmit special signals to the remote system. The keyword EOT sends the End of
Transmission character. On UNIX systems this is usually the End of File character, which is a CTRLD. The BREAK keyword sends a line break to the remote system. The three remaining keywords
define processing characteristics for the script itself.
The TIMEOUT keyword defines the amount of time to wait for an expected string. Because it is
defined inside the script, the timeout value can be changed for each expected string. For example,
assume you want to allow the remote server 30 seconds to display the initial Username> prompt but
only 5 seconds to display Password> once the username has been sent. Enter this script command:
TIMEOUT 30 name> karen TIMEOUT 5 word> beach%PARTY
The ABORT keyword and the REPORT keyword are similar. They both define strings that, when
received, cause a special action to take place. The ABORT keyword defines strings that cause the
script to abort if they are received when the system is expecting the string CONNECT from the
modem. The REPORT keyword defines substrings that determine what messages received on the
serial port should be written to stderr or the report file. A sample chat script file illustrates both of
these keywords:
REPORT CONNECT
ABORT BUSY
file:///C|/mynapster/Downloads/warez/tcpip/appa_03.htm (2 of 4) [2001-10-15 09:19:11]

[Appendix A] A.3 chat

ABORT 'NO CARRIER'
ABORT 'RING - NO ANSWER'
"" ATDT5551234
CONNECT \r
name> karen
word> beach%PARTY
The first line says that any message received by the script that contains the word CONNECT will be
logged. If the -r command-line option was used when chat was started, the message is logged in the
file defined by that option. Otherwise the message is displayed on stderr. The point of this command
is to display the modem's connect message to the user. For example: the complete message might be
CONNECT 28,800 LAPM/V, which tells the user the link speed and the transmission protocol used
by the modems. The CONNECT message means success. The next three lines of the script begin with
the keyword ABORT and define the modem messages that mean failure. If the modem responds with
BUSY, NO CARRIER, or RING - NO ANSWER, the script aborts.
The last four lines are the basic expect/send pairs we have seen repeatedly in this section. We expect
nothing ("") and send the dial command to the modem (ATDT). We expect CONNECT from the
modem and send a carriage return (\r) to the remote server. We expect Username> from the remote
server and send karen. Finally, we expect Password> from the server and send beach%PARTY.
chat extends the standard expect/send pair with an alternate send and an alternate expect to improve
robustness. You may define an alternate send string and an alternate expect value to be used when the
script times out waiting for the primary expected value. The alternate send and the alternate expect are
indicated in the script by preceding them with dashes. For example:
gin:-BREAK-gin: becca
In this sample we wait for the string gin: and send the string becca. The first string and the last
string compose the standard expect/send pair. The alternate send/expect is only used if the timer
expires and the expected gin: string has not been received. When this occurs, the script sends a line
break, restarts the timer, and waits for gin: again, because that is what our alternate send/expect pair
(-BREAK-gin:) tells the script to do. Note that unlike the standard expect/send pair, in the
send/expect pair a value is transmitted before a string is expected, i.e., the send comes before the
expect. Another example more in keeping with our other script examples is:
name>—name> karen
Here the script expects the name> string. If it is not received, the script sends an empty line, which is
simply a carriage return, and again waits for the name> string. This action is dictated by the alternate
send/expect pair, —name>. The pair begins with a dash that signals the
start of the send string, but the next character is the second dash that marks the beginning of the
alternate expect string. There is no send string. It is this "empty string" that causes the script to send a
single return character. This example is more common than the BREAK example shown above,
though a little harder to explain.
file:///C|/mynapster/Downloads/warez/tcpip/appa_03.htm (3 of 4) [2001-10-15 09:19:11]

[Appendix A] A.3 chat

The carriage return character is not the only special character that can be sent from a chat script. chat
provides several escape sequences for sending and receiving special characters. Table 13.2 lists these.
Table A.2: chat Escape Sequences
Escape Sequence Meaning
\b
The backspace character.
\
Send without the terminating return character.
\d
Delay sending for one second.
\K
Send a BREAK.
\n
Send a newline character.
\N
Send a null character.
\
Delay sending 1/10th of a second.
\q
Send the string but don't log it.
\r
The carriage return.
\s
The space character.
\t
The tab character.
\\
The backslash character.
\ddd
The ASCII character with the octal value ddd.
^C
A control character.
All of the escape sequences start with a backslash (\) except for the sequence used to enter a control
character. Control characters are entered as a caret (^) followed by an uppercase letter. For example
control X is entered as ^X. The escape sequences that are described in Table 13.2 with the words
"send" or "sending" can only be used in a send string; all others can be used in either a send or expect
string. Several escape sequences are used in the following example:
"" \d\d^G\p^G\p\p^GWake\sUp!\nSleepy\sHead!
Expect nothing (""). Wait two seconds (\d\d). Send three ASCII BELL characters, which is CTRLG on the keyboard, at intervals of 1/10 of a second (^G\p^G\p\p^G). Send the string Wake Up!.
Go to a new line (\n) and send the string Sleepy Head!.

Previous: A.2 The PPP
Daemon
A.2 The PPP Daemon

TCP/IP Network
Administration
Book Index

Next: B. A gated Reference
B. A gated Reference

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/appa_03.htm (4 of 4) [2001-10-15 09:19:11]

[Appendix B] A gated Reference

Previous: A.3 chat

Appendix B

Next: B.2 The gated
Configuration Language

B. A gated Reference
Contents:
The gated Command
The gated Configuration Language
Directive Statements
Trace Statements
Options Statements
Interface Statements
Definition Statements
Protocol Statements
static Statements
Control Statements
The Aggregate Statements
This appendix covers the syntax of the gated command and the gated configuration language. As a
reference to the gated configuration language, this appendix stands on its own. But to fully
understand how to configure gated, use this reference in conjunction with the sample configuration
files in Chapter 7, Configuring Routing .
gated is constantly being improved. As it is upgraded, the command language changes. Refer to the
latest manpages for the most recent information about gated.

B.1 The gated Command
The syntax of the gated command is:
gated [-c] [-C] [-n] [-N] [-t trace_options] [-f config_file] [trace_file]
The -c and -n command-line options debug the routing configuration file without impacting the
network or the kernel routing table. Frequently, these debugging options are used with a test
configuration identified by the -f config_file option:
file:///C|/mynapster/Downloads/warez/tcpip/appb_01.htm (1 of 4) [2001-10-15 09:19:11]

[Appendix B] A gated Reference

-c
Tells gated to read the configuration file and check for syntax errors. When gated finishes
reading the configuration file, it produces a snapshot of its status and then terminates. It writes
the snapshot to /usr/tmp/gated_dump. Running gated with the -c option does not require
superuser privilege, and it is not necessary to terminate the active gated process.
-C
Checks the configuration file for syntax errors. gated exits with a status 1 if there are errors
and 0 if there are none. Because this provides exit status, it is useful for script files.
-n
Tells gated not to update the kernel routing table. This is used to test the routing configuration
with real routing data without interfering with system operation.
-f config_file
Tells gated to read the configuration from config_file instead of from the default
configuration file, /etc/gated.conf. Used in conjunction with the -c option, -f checks a new
configuration without interfering with the currently running gated configuration.
The -N command-line option prevents gated from running in background mode as a daemon. This
option is used when gated is started from inittab. By default, gated runs as a daemon.
The command-line arguments trace_options and trace_file are used for protocol tracing.
The trace_file argument names the file to which the trace output is written. If a file is not
specified, the trace is written to the standard output. Tracing usually produces a large amount of
output.
The command-line options used for tracing are:
-t
This option turns on tracing. If -t is specified with no trace_options, gated defaults to
general tracing, which traces normal protocol interactions and routing table changes. gated
always logs protocol errors even if no tracing is specified. You can define several different
trace_options, all of which are described later in this appendix. A few
trace_options (detail, send, recv) cannot be specifed on the gated command line. Two
others are most useful when they are defined on the command line:
symbols
Traces the symbols read from the kernel, which is primarily of interest to developers
debugging the interaction of gated and the kernel.
iflist
file:///C|/mynapster/Downloads/warez/tcpip/appb_01.htm (2 of 4) [2001-10-15 09:19:11]

[Appendix B] A gated Reference

Traces the list of interfaces read from the kernel. Use this to determine what interfaces
are detected by the kernel interface scan.
The advantage of placing a trace option on the command line is that it can trace activities that happen
before the configuration file is processed. For the two options listed above, this is an essential
advantage. For other options it is not very important. Most trace options are specified in the
configuration file. See the traceoptions command later in this appendix for more details.

B.1.1 Signal Processing
gated processes the following signals:
SIGHUP
Tells gated to reread the configuration file. The new configuration replaces the one that gated
is currently running. SIGHUP loads the new configuration file without interrupting gated
service. SIGHUP is available for quick configuration changes. At most sites, the routing
configuration changes infrequently. The few times you need to change to a new configuration,
terminate gated and rerun it with the new configuration. This is a more accurate test of how
things will run at the next boot.
SIGINT
Tells gated to snapshot its current state to the file /usr/tmp/gated_dump.
SIGTERM
Tells gated to shut down gracefully. All protocols are shut down following the rules of that
protocol. For example, EGP sends a CEASE message and waits for it to be confirmed.
SIGTERM removes from the kernel routing table all routes learned via the exterior routing
protocols. If you need to preserve those routes while gated is out of operation, use SIGKILL.
SIGKILL
Tells gated to terminate immediately and dump core. Routes are not removed from the routing
table, and no graceful shutdown is attempted.
SIGUSR1
Tells gated to toggle tracing. If no trace flags are set, SIGUSR1 has no effect. But if tracing is
enabled, the first SIGUSR1 causes gated to toggle off tracing and to close the trace file. The
next SIGUSR1 turns tracing back on and opens the trace file. When the trace file is closed, it
can be moved or removed without interfering with the operation of gated. Use this to
periodically empty out the trace file to prevent it from becoming too large.
SIGUSR2
Tell gated to check for changes in the status of the network interfaces.

file:///C|/mynapster/Downloads/warez/tcpip/appb_01.htm (3 of 4) [2001-10-15 09:19:11]

[Appendix B] A gated Reference

The following is an example of gated signal handling. First, the SIGUSR1 signal is passed to the
gated process using the process ID obtained from the gated.pid file (/var/run/gated.pid in this case).
# kill -USR1 `cat /var/run/gated.pid`
Next, the old trace file (/usr/tmp/gated.log in this case) is removed, and gated is passed another
SIGUSR1 signal.
# rm /usr/tmp/gated.log
# kill -USR1 `cat /etc/gated.pid`
After receiving the second signal, gated opens a fresh trace file (still named /usr/tmp/gated.log). An ls
shows that the new file has been created.
# ls -l /usr/tmp/gated.log
-rw-rw-r-- 1 root

Previous: A.3 chat
A.3 chat

105 Jul

TCP/IP Network
Administration
Book Index

6 16:41 /usr/tmp/gated.log

Next: B.2 The gated
Configuration Language
B.2 The gated Configuration
Language

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/appb_01.htm (4 of 4) [2001-10-15 09:19:11]

[Appendix B] B.2 The gated Configuration Language

Previous: B.1 The gated
Command

Appendix B
A gated Reference

Next: B.3 Directive
Statements

B.2 The gated Configuration Language
The gated configuration language is a highly structured language similar to C in appearance.
Comments either begin with a #, or they begin with /* and end with */. gated configuration
statements end with a semicolon, and groups of associated statements are enclosed in curly braces.
The language structure is familiar to most UNIX system administrators, and the structure makes it
easy to see what parts of the configuration are associated with each other. This is important when
multiple protocols are configured in the same file.
The configuration language is composed of nine types of statements. Two statement types, directive
statements and trace statements, can occur anywhere in the gated.conf file and do not directly relate to
the configuration of any protocol. These statements provide instructions to the parser and control
tracing from within the configuration file. The other seven statement types are options statements,
interface statements, definition statements, protocol statements, static statements, control statements,
and aggregate statements. These statements must appear in the configuration file in the correct order,
starting with options statements and ending with aggregate statements. Entering a statement out of
order causes an error when parsing the file.
The remainder of this appendix provides a description of all commands in the gated configuration
language, organized by statement type.

Previous: B.1 The gated
Command
B.1 The gated Command

TCP/IP Network
Administration
Book Index

Next: B.3 Directive
Statements
B.3 Directive Statements

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/appb_02.htm [2001-10-15 09:19:12]

[Appendix B] B.3 Directive Statements

Previous: B.2 The gated
Configuration Language

Appendix B
A gated Reference

Next: B.4 Trace Statements

B.3 Directive Statements
Directive statements provide direction to the gated command language parser about "include" files.
An include file is an external file whose contents are parsed into the configuration as if it were part of
the original gated.conf file. Include files can contain references to other include files, and these
references can be nested up to 10 levels deep.
The two directive statements are:
%include filename
Identifies an include file. The contents of the file are "included" in the gated.conf file at the
point in the gated.conf file where the %include directive is encountered. filename is any
valid UNIX filename. If filename is not fully qualified, i.e., does not begin with a /, it is
considered to be relative to the directory defined in the %directory directive.
%directory pathname
Defines the directory where the include files are stored. When it is used, gated looks in the
directory identified by pathname for any include file that does not have a fully qualified
filename.
Unless you have a very complex routing configuration, avoid using include files. In a complex
environment, segmenting a large configuration into smaller, more easily understood segments can be
helpful, but most gated configurations are very small. One of the great advantages of gated is that it
combines the configuration of several different routing protocols into a single file. If that file is small
and easy to read, segmenting the file unnecessarily complicates things.

Previous: B.2 The gated
Configuration Language
B.2 The gated Configuration
Language

TCP/IP Network
Administration
Book Index

file:///C|/mynapster/Downloads/warez/tcpip/appb_03.htm (1 of 2) [2001-10-15 09:19:12]

Next: B.4 Trace Statements
B.4 Trace Statements