connecting to an external company - via /dev/tty1 - the modem connects to the compatny but after approximately 3 secs tells me that my NUA and phone numbers are incorrect - if this was the case then the call would not even logon to the server - anything I can check ?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Modem bombing out
- Thread starter maxcrook
- Start date
That is a funny message. Are you sure they do not have some kind of security
on that port...or a process where it calls you back and then checks the number
you called in on?
If not.....This doc should help
Troubleshooting Modem Problems
A convenient way to debug any modem problem is to remove the modem
and attach an ASCII terminal (with an interposer or null modem) to
the same port and cabling as the modem. Set up the terminal with
the same line speed, bits per character, and parity as
the modem. A login herald should be displayed on the screen. If
the herald is displayed on the terminal screen, then the problem is
quickly isolated to the modem configuration.
The following tips will help you isolate problems associated with
modem connections:
Problem Resolution
Respawning too rapidly
The getty program is respawned by init.
Messages on console or errpt
If init sees that it has to respawn any program
more that five times in 225 seconds, it will
display the message on the console and not
respawn it for a period of time. The solution is to
find out why getty is dying. There may be
several causes:
Incorrect modem settings, usually as a
result of having CD strapped high on the
modem or cabling and also having either
"echo" or "command response" turned on.
(CD can also be assumed high by adding
clocal in the runmodes and/or logmodes in
the port configuration or also forced on
the 128 port.)
Toggling of the CD signal. The getty
process will die every time CD is toggled
from an on to off state. (This action could
be caused by a number of reasons. Be
sure to verify that the cable is properly
shielded. Logging in and out several times
in rapid succession can cause this.)
No login prompt displayed after connection to modem
Make sure getty is running on the port. If it is,
verify that the carrier detect connection to
modem signal is being raised after the remote
side has connected to the modem. If CD is being
properly asserted, then verify the modem is
connected to the right port. If you still do not see
login, then attach a terminal with interposer to the
cable in place of the modem and verify that a
login prompt does appear. If you still don't see a
prompt, try to echo characters to the terminal
screen to verify the cable and hardware are
functioning properly.
When a remote modem connects, it immediately disconnects
Verify that the modem is talking to the server at
the same speed at which the server is listening to
the modem. Try different baud rates for the tty,
or program the modem to lock DTE speed to
match the speed of the tty port. Verify that the
modem or port is not keeping the carrier detect
signal high or that the port is already being used
by another process.
Getting garbage characters instead of a login prompt
This is due to a difference in protocols. Be sure
to verify that the modem and the tty port agree
on the same parity, baud rate, flow control, and
character size.
Sometimes, after a successful session, no one is able to login
It may be that the modem does not reset after
disconnect. See the modem manual to see how
the modem can be set to reset after an on to off
DTR transition.
Receiver buffer overruns in errpt
The UART chip buffer is being overrun. Lower
the value of the receive trigger in SMIT for the
tty. This solution is only valid for the native, 8- or
16-port asynchronous adapters. Verify that the
modem and tty port are using the same flow
control.
ttyhog errors in errpt
Modem and tty either do not agree on flow
control, or no flow control is taking place.
/usr/lib/uucp/Dialers Sample File Entries
The examples in this section are supplied without any warranty and will work
as is for the models mentioned, but may not meet your specific needs. Some
modifications will be required to meet your individual needs. Consult your modem
manual for a more detailed explanation of the settings.
To use the settings to program the modem, you need an entry in the
/usr/lib/uucp/Systems file such as:
hayes Nvr HayesPRGM Any
The /usr/lib/uucp/Devices file should have an entry such as:
HayesPRGM tty0 - 2400 HayesProgrm2400
With the above two entries made, use the following cu command to program the
modem:
cu -d hayes
on that port...or a process where it calls you back and then checks the number
you called in on?
If not.....This doc should help
Troubleshooting Modem Problems
A convenient way to debug any modem problem is to remove the modem
and attach an ASCII terminal (with an interposer or null modem) to
the same port and cabling as the modem. Set up the terminal with
the same line speed, bits per character, and parity as
the modem. A login herald should be displayed on the screen. If
the herald is displayed on the terminal screen, then the problem is
quickly isolated to the modem configuration.
The following tips will help you isolate problems associated with
modem connections:
Problem Resolution
Respawning too rapidly
The getty program is respawned by init.
Messages on console or errpt
If init sees that it has to respawn any program
more that five times in 225 seconds, it will
display the message on the console and not
respawn it for a period of time. The solution is to
find out why getty is dying. There may be
several causes:
Incorrect modem settings, usually as a
result of having CD strapped high on the
modem or cabling and also having either
"echo" or "command response" turned on.
(CD can also be assumed high by adding
clocal in the runmodes and/or logmodes in
the port configuration or also forced on
the 128 port.)
Toggling of the CD signal. The getty
process will die every time CD is toggled
from an on to off state. (This action could
be caused by a number of reasons. Be
sure to verify that the cable is properly
shielded. Logging in and out several times
in rapid succession can cause this.)
No login prompt displayed after connection to modem
Make sure getty is running on the port. If it is,
verify that the carrier detect connection to
modem signal is being raised after the remote
side has connected to the modem. If CD is being
properly asserted, then verify the modem is
connected to the right port. If you still do not see
login, then attach a terminal with interposer to the
cable in place of the modem and verify that a
login prompt does appear. If you still don't see a
prompt, try to echo characters to the terminal
screen to verify the cable and hardware are
functioning properly.
When a remote modem connects, it immediately disconnects
Verify that the modem is talking to the server at
the same speed at which the server is listening to
the modem. Try different baud rates for the tty,
or program the modem to lock DTE speed to
match the speed of the tty port. Verify that the
modem or port is not keeping the carrier detect
signal high or that the port is already being used
by another process.
Getting garbage characters instead of a login prompt
This is due to a difference in protocols. Be sure
to verify that the modem and the tty port agree
on the same parity, baud rate, flow control, and
character size.
Sometimes, after a successful session, no one is able to login
It may be that the modem does not reset after
disconnect. See the modem manual to see how
the modem can be set to reset after an on to off
DTR transition.
Receiver buffer overruns in errpt
The UART chip buffer is being overrun. Lower
the value of the receive trigger in SMIT for the
tty. This solution is only valid for the native, 8- or
16-port asynchronous adapters. Verify that the
modem and tty port are using the same flow
control.
ttyhog errors in errpt
Modem and tty either do not agree on flow
control, or no flow control is taking place.
/usr/lib/uucp/Dialers Sample File Entries
The examples in this section are supplied without any warranty and will work
as is for the models mentioned, but may not meet your specific needs. Some
modifications will be required to meet your individual needs. Consult your modem
manual for a more detailed explanation of the settings.
To use the settings to program the modem, you need an entry in the
/usr/lib/uucp/Systems file such as:
hayes Nvr HayesPRGM Any
The /usr/lib/uucp/Devices file should have an entry such as:
HayesPRGM tty0 - 2400 HayesProgrm2400
With the above two entries made, use the following cu command to program the
modem:
cu -d hayes
- Status