Библиотека сайта rus-linux.net
17. Questions about chat
The chat program is packages with the pppd executable. This is not an endorsement for chat. Any program which will arrange to start the PPP protocol on the remote system may be used. However, since chat is included with pppd, many people use it. There are only a few common questions about chat.
17.1 My modem wont dial when I run chat
The modem is required to be in the command mode to issue dial commands. If your modem is \online\ then characters sent to the modem will be sent to the remote system.
If possible, configure the modem to monitor the DTR signal and to return to the command mode when the DTR signal drops. This will permit the computer to force the modem back to the command mode when the pppd process terminates at the end of a connection. It will then be in the proper state when the next execution attempts to dial the telephone.
If you can\t do this then you should change the dial sequence so that it is similar to the following. It will ensure that the modem is in the command state prior to attempting to send the dial sequence.
TIMEOUT 3 \\ \rAT OK-+++\c-OK AT&D2&C1 TIMEOUT 60 OK ATDT555-1212 CONNECT
The commands will change the timeout period to three seconds. This accommodates the guard time period used by many modems. It will then send AT to the modem and look for its response of OK. If it is not received in the three seconds, it will send the +++ sequence to the modem and wait for the modem to present the expected OK response. Once it receives the valid response it will configure the modem and dial the telephone number.
17.2 The modem dials only on every second attempt
Please refer to the above answer. It is usually the same issue.
17.3 The chat script stops after sending the account name and it never receives the password prompt.
Some systems, notably SCO, will flush the receive buffers after writing the prompts for user name and password. The chat program normally transmits the response immediately upon seeing the prompt. The result is that the reply from chat is flushed by SCO. The chat program continues to wait for the password prompt. However, the remote system is still waiting for the user to enter the account name.
The solution is simple. Slow down the responses from chat so that there is time for the remote system to flush the receive buffer before chat starts to send the response. Chat supports this with the \d parameter. Change the response strings similar to the following:
ogin:--ogin: \d\daccount assword: \d\dhello2u2
17.4 The chat script stops before finishing and fails to make the connection
A common method of using chat is to use the connect option and have it directly run the chat program, i.e. connect "chat ...". What is not so obvious is the method by which pppd implements the connect processing.
The pppd process uses the execl() function to start a shell. The shell is given the command line string which you supplied with the connect option. This has several advantages in that the parameters do not need to be parsed by pppd, they may be expanded, the path is automatically searched, etc. However, it does have some disadvantages as well.
The disadvantage is that the shell will re-interpret the option string again for special characters and act upon them. It will use the \ character to take the next character as a different meaning, it will use the & character to start a new sub-shell, and it will use the < and > to do I/O redirection.
So, if your prompt string is "protocol>" and you use just the string protocol> or even > then the shell will cause chat to fail to run. This is not a problem with chat. This is not a problem with the shell. They are both doing exactly what is expected.
So, how do you actually use the string protocol> as a prompt? Well, the answer is simple. Put a \ before the > character as in protocol\>. This tells the shell that the > is not an I/O redirection sequence but a simple character which is to be given to the chat program just like any other.
The same thing is required for the modem configuration options of AT&D2, etc. The & needs to be quoted as in AT\&D2.
The chat program also recognizes the \ character as being special within its own processing. This is performed so that strings may have special characters within them such as \r for a carriage return. If your prompt or the reply contains a \ then you need to give chat \\ for each \ character that you wish to use. (Remember that the shell will also need \\ for each of those as well if you don't put the sequence within quotes.)
17.5 When I attempt to run chat, it says that the -l parameter is invalid. Why?
There was a time when chat had the ability to set a lock file for the modem device. The name of the file was given to chat with the parameter -l.
However, that was a seriously bad idea and should not have been in the code in the first place.
The reason is that chat is a filter. It does not attempt to configure the modem for the proper rate. So, what people would do is run stty to set the rate, then run chat, and then attempt to run pppd. This was definitely not the way to do the connection.
The serial port sharing only works if all of the programs on your system follow the same rules and play by the same game. If you want to share the serial port then you need to use a lock file. This lock file must be created using the proper method before the serial port is touched. You are not permitted to run stty on the serial port until the lock file is first created.
Consider what would happen if you had run chat, and chat was in the middle of the dial sequence and then some cron event occurred which launched another program. That program just changed the BPS rate on your modem without attempting to lock the serial device first. I can tell you what would happen. The chat connection script won't complete.
So, for that reason, since chat is a filter and not meant to be a controlling program, the lock option was removed. Chat is not able to create a lock file for the modem. The lock file must be created by the program which configures the serial port and then runs chat, such as pppd.
17.6 I ran chat. It seems to want to use the local terminal as the modem and it does not talk to the modem. How do I specify the modem name to chat?
Chat is in a class of programs called a \filter\. That is, it reads from the standard input, does some processing internally, and writes to the standard output.
So, if you really want to just run chat and have it talk to a modem then you need to use the I/O redirection operators < and > so that the standard input and output are redirected to the modem.
HOWEVER, if you are using chat with pppd, please do not run chat first and then attempt to run pppd after it. You should only use the combination of chat and pppd if you use the connect option for pppd to run the chat program.
The reason for this is that pppd will automatically redirect the standard input and standard output to the appropriate modem device before it runs the connect script (and chat). In addition, the necessary device locking will have been performed before it attempts to run the chat program.
If you just run chat first and then expect to run pppd, your system will fail should you have another program which is sharing the serial device. The locking will not have been performed, chat will not have re-configured the serial device so that it has the proper transmission rate, parity, stop bits, etc. and then when the other program, such as mgetty, comes along it will find that the lock file is not valid and re-configure the modem again. In so doing, it will destroy the use of the modem by chat and chat or pppd will fail.
17.7 When I run pppd and chat along with mgetty then the connection does not start. If I stop mgetty, then pppd will work. Why?
For the serial port to be shared properly, a lock file is needed between the use of the serial port by mgetty and the use by pppd (and chat).
The pppd process uses the FSSTND location of /var/lock/LCK..ttyS0 to lock the device called 'ttyS0'.
There have been some pre-built binaries of mgetty in some distributions which use the much older location of /usr/spool/uucp/LCK..ttyS0.
In addition to the file location, the file format must be the same. There are two common methods of recording the pid information in the file. The first is the older method, used commonly by some pre-built binaries for the kermit terminal emulator, of storing the pid as a binary value. You can tell this format in that the lock file is four bytes in size.
The more modern method is to store the pid as an ASCII string. This file has a size of eleven bytes (ten bytes for the pid, one for the trailing newline character.)
If the file format does not match what mgetty expects then mgetty treats the lock as being invalid and seizes the device, drops the DTR (which usually hangs up on the connection), and reconfigures the modem.
The other cause for the condition is that you simply forgot to tell pppd that it must lock the serial port. To tell pppd that it needs to lock the serial port, use the option 'lock' when you run pppd.
In the context of the lock file, the name of the lock file is formed from the name of the serial device. That is good for the most part. The problem comes when people use 'modem' and 'ttyS0' to be the same thing. Some people have a symbolic link from /dev/modem to /dev/ttyS0. They then forget that mgetty is using the name ttyS0 for the name of the serial port and they use /dev/modem when they run pppd, telling it to create the lock. The pppd process does so, but the lock file created is called "LCK..modem". Then mgetty comes along and does not see that the serial device is locked (because there is no "LCK..ttyS0" file) and drops the DTR signal and the PPP connection is broken.
So, either use /dev/modem or /dev/ttyS0 for your modem. Choose one name. Get rid of the other. Use that name everywhere, not just in "most" of the places, but in "every" place.
We have been working on a solution to this problem. It involves getting rid of the reliance upon the name of the serial device and using the values that the operating systems really uses, the major and minor device numbers. However, that is not in place yet. Until it is, be careful and use the proper names for the devices on the system and you should not have a problem.
Previous Next Table of Contents