]> git.ozlabs.org Git - ppp.git/commitdiff
Initial revision
authorPaul Mackerras <paulus@samba.org>
Fri, 28 Apr 1995 05:27:25 +0000 (05:27 +0000)
committerPaul Mackerras <paulus@samba.org>
Fri, 28 Apr 1995 05:27:25 +0000 (05:27 +0000)
chat/Makefile.aix4 [new file with mode: 0644]
chat/Makefile.linux [new file with mode: 0644]
chat/Makefile.osf [new file with mode: 0644]
chat/chat.8 [new file with mode: 0644]

diff --git a/chat/Makefile.aix4 b/chat/Makefile.aix4
new file mode 100644 (file)
index 0000000..8280699
--- /dev/null
@@ -0,0 +1,21 @@
+#
+# Makefile for chat on AIX 4.1
+#
+
+#ifndef BINDIR
+BINDIR=/usr/sbin
+#endif
+
+CC=xlc
+CFLAGS= -D_NO_PROTO
+
+all:   chat
+
+chat: chat.o
+       $(CC) -o chat chat.o
+
+install:
+       install -f $(BINDIR) chat
+
+clean:
+       rm -f *~ *.o chat
diff --git a/chat/Makefile.linux b/chat/Makefile.linux
new file mode 100644 (file)
index 0000000..d46583f
--- /dev/null
@@ -0,0 +1,27 @@
+#      $Id: Makefile.linux,v 1.1 1995/04/28 05:26:48 paulus Exp $
+
+BINDIR=/usr/etc
+
+CDEF1= -DTERMIOS                       # Use the termios structure
+CDEF2= -DPIDSTRING                     # I like ascii pid values
+CDEF3= -DLOCK_DIR=\"/usr/spool/uucp\"  # Directory for lock file
+CDEF4= -DSIGTYPE=void                  # Standard definition
+CDEF5= -UNO_SLEEP                      # Use the usleep function
+CDEF6= -DFNDELAY=O_NDELAY              # Old name value
+CDEFS= $(CDEF1) $(CDEF2) $(CDEF3) $(CDEF4) $(CDEF5) $(CDEF6)
+
+CFLAGS=        -O2 -N $(CDEFS)
+
+all:   chat
+
+chat:  chat.o
+       $(CC) -o chat chat.o
+
+chat.o:        chat.c
+       $(CC) -c $(CFLAGS) -o chat.o chat.c
+
+install: chat
+       install -c chat $(BINDIR)
+
+clean:
+       rm -f chat.o chat *~
diff --git a/chat/Makefile.osf b/chat/Makefile.osf
new file mode 100644 (file)
index 0000000..021b399
--- /dev/null
@@ -0,0 +1,14 @@
+#
+# Makefile for chat on OSF/1
+#
+
+all:   chat
+
+chat: chat.o
+       $(CC) -o chat chat.o
+
+install: chat
+       installbsd -c chat $(BINDIR)/chat
+
+clean:
+       rm -f *~ *.o chat
diff --git a/chat/chat.8 b/chat/chat.8
new file mode 100644 (file)
index 0000000..93eb8a6
--- /dev/null
@@ -0,0 +1,251 @@
+.\" -*- nroff -*-
+.\" manual page [] for chat 1.8
+.\" $Id: chat.8,v 1.1 1995/04/28 05:27:25 paulus Exp $
+.\" SH section heading
+.\" SS subsection heading
+.\" LP paragraph
+.\" IP indented paragraph
+.\" TP hanging label
+.TH CHAT 8 "17 April 1994" "Chat Version 1.8"
+.SH NAME
+chat \- Automated conversational script with a modem
+.SH SYNOPSIS
+.B chat
+[
+.I options
+]
+.I script
+.SH DESCRIPTION
+.LP
+The \fIchat\fR program defines a conversational exchange between the
+computer and the modem. Its primary purpose is to establish the
+connection between the Point-to-Point Protocol Daemon (\fIpppd\fR) and
+the remote's \fIpppd\fR process.
+.SH OPTIONS
+.TP
+.B -f \fI<chat file>
+Read the chat script from the chat \fIfile\fR. The use of this option
+is mutually exclusive with the chat script parameters. The user must
+have read access to the file. Multiple lines are permitted in the
+file. Space or horizontal tab characters should be used to separate
+the strings.
+.TP
+.B -l \fI<lock file>
+Perform the UUCP style locking using the indicated lock file.
+.IP
+If the file could not be created then the \fIchat\fR program will
+fail. The lock file will be deleted only if the \fIchat\fR program
+fails to perform the script for any reason. If the script is
+successful the lock file will be left on the disk. It is expected that
+the lock file will be deleted when the \fIpppd\fR process no longer
+wishes to use the serial device.
+.IP
+The use of a lock file with 
+.I chat
+and 
+\fIpppd\fR\'s
+.I lock
+option should not be used at the same time. They are mutually
+exclusive options and will cause one or the other program to fail to
+achieve the required lock if you use both.
+.TP
+.B -t \fI<timeout>
+Set the timeout for the expected string to be received. If the string
+is not received within the time limit then the reply string is not
+sent. An alternate reply may be sent or the script will fail if there
+is no alternate reply string. A failed script will cause the
+\fIchat\fR program to terminate with a non-zero error code.
+.TP
+.B -v
+Request that the \fIchat\fR script be executed in a verbose mode. The
+\fIchat\fR program will then log all text received from the modem and
+the output strings which it sends to the SYSLOG.
+.TP
+.B script
+If the script is not specified in a file with the \fI-f\fR option then
+the script is included as parameters to the \fIchat\fR program.
+.SH CHAT SCRIPT
+.LP
+The \fIchat\fR script defines the communications.
+.LP
+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:
+.IP
+ogin:-BREAK-ogin: ppp ssword: hello2u2
+.LP
+This line indicates that the \fIchat\fR program should expect the string
+"ogin:". If it fails to receive a login prompt within the time interval
+allotted, it is to send a break sequence to the remote and then expect the
+string "ogin:". If the first "ogin:" is received then the break sequence is
+not generated.
+.LP
+Once it received the login prompt the \fIchat\fR program 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.
+.LP
+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.
+.LP
+The expect sequence should contain only what is needed to identify the
+string. Since it is normally stored on a disk file, 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.
+.LP
+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:".
+.LP
+A very simple script might look like this:
+.IP
+ogin: ppp ssword: hello2u2
+.LP
+In other words, expect ....ogin:, send ppp, expect ...ssword:, send hello2u2.
+.LP
+In actual practice, simple scripts are rare. At the vary least, you
+should include sub-expect sequences should the original string not be
+received. For example, consider the following script:
+.IP
+ogin:--ogin: ppp ssowrd: hello2u2
+.LP
+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.
+.SH ABORT STRINGS
+Many modems will report the status of the call as a string. These
+strings may be \fBCONNECTED\fR or \fBNO CARRIER\fR or \fBBUSY\fR. 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 \fBBUSY\fR while the next time it may receive \fBNO CARRIER\fR.
+.LP
+These "abort" strings may be specified in the script using the \fIABORT\fR
+sequence. It is written in the script as in the following example:
+.IP
+ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ATDT5551212 CONNECT
+.LP
+This sequence will expect nothing; and then send the string ATZ. The
+expected response to this is the string \fIOK\fR. When it receives \fIOK\fR,
+the string ATDT5551212 to dial the telephone. The expected string is
+\fICONNECT\fR. If the string \fICONNECT\fR is received the remainder of the
+script is executed. However, should the modem find a busy telephone, it will
+send the string \fIBUSY\fR. 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 \fINO CARRIER\fR, it will abort
+for the same reason. Either string may be received. Either string will
+terminate the \fIchat\fR script.
+.SH TIMEOUT
+The initial timeout value is 45 seconds. This may be changed using the \fB-t\fR
+parameter.
+.LP
+To change the timeout value for the next expect string, the following
+example may be used:
+.IP
+ATZ OK ATDT5551212 CONNECT TIMEOUT 10 ogin:--ogin: TIMEOUT 5 assowrd: hello2u2
+.LP
+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.
+.LP
+The timeout, once changed, remains in effect until it is changed again.
+.SH SENDING EOT
+The special reply string of \fIEOT\fR 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.
+.PR
+The EOT sequence may be embedded into the send string using the
+sequence \fI^D\fR.
+.SH GENERATING BREAK
+The special reply string of \fIBREAK\fR will cause a break condition
+to be sent. The break is a special signal on the transmitter. The
+normal processing on the receiver is to change the transmission rate.
+It may be used to cycle through the available transmission rates on
+the remote until you are able to receive a valid login prompt.
+.PR
+The break sequence may be embedded into the send string using the
+\fI\\K\fR sequence.
+.SH ESCAPE SEQUENCES
+The expect and reply strings may contain escape sequences. All of the
+sequences are legal in the reply string. Many are legal in the expect.
+Those which are not valid in the expect sequence are so indicated.
+.TP
+.B ''
+Expects or sends a null string. If you send a null string then it will still
+send the return character. This sequence may either be a pair of apostrophe
+or quote characters.
+.TP
+.B \\\\b
+represents a backspace character.
+.TP
+.B \\\\c
+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.
+.I (not valid in expect.)
+.TP
+.B \\\\d
+Delay for one second. The program uses sleep(1) which will delay to a
+maximum of one second.
+.I (not valid in expect.)
+.TP
+.B \\\\K
+Insert a BREAK
+.I (not valid in expect.)
+.TP
+.B \\\\n
+Send a newline or linefeed character.
+.TP
+.B \\\\N
+Send a null character. The same sequence may be represented by \\0.
+.I (not valid in expect.)
+.TP
+.B \\\\p
+Pause for a fraction of a second. The delay is 1/10th of a second.
+.I (not valid in expect.)
+.TP
+.B \\\\q
+Suppress writing the string to the SYSLOG file. The string ?????? is
+written to the log in its place.
+.I (not valid in expect.)
+.TP
+.B \\\\r
+Send or expect a carriage return.
+.TP
+.B \\\\s
+Represents a space character in the string. This may be used when it
+is not desirable to quote the strings which contains spaces. The
+sequence 'HI TIM' and HI\\sTIM are the same.
+.TP
+.B \\\\t
+Send or expect a tab character.
+.TP
+.B \\\\\\\\
+Send or expect a backslash character.
+.TP
+.B \\\\ddd
+Collapse the octal digits (ddd) into a single ASCII character and send that
+character.
+.I (some characters are not valid in expect.)
+.TP
+.B \^^C
+Substitute the sequence with the control character represented by C.
+For example, the character DC1 (17) is shown as \^^Q.
+.I (some characters are not valid in expect.)
+.SH SEE ALSO
+Additional information about \fIchat\fR scripts may be found with UUCP
+documentation. The \fIchat\fR script was taken from the ideas proposed by the
+scripts used by the \fIuucico\fR program.
+.LP
+uucico(1), uucp(1)
+.SH COPYRIGHT
+The \fIchat\fR program is in public domain. This is not the GNU public
+license. If it breaks then you get to keep both pieces.