Re: Setting hardware flow control on serial port
From: John Pezzano (jpezz_at_myway.com)
Date: 05/20/03
- Next message: Robert Pouliot: "Re: N Class Question"
- Previous message: Robert: "Re: cron question"
- In reply to: Martin Stenzel: "Setting hardware flow control on serial port"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 20 May 2003 00:43:21 GMT
Martin,
Attached are some files which really explain modems on HP-UX and how to
configure and check HW flow control.
John
Martin Stenzel wrote:
> Hi there,
>
> I successfully set up PPP which was not that intuitive.
> Now I want to set up hardware flow control on both serial port and
> modem, therefore I created the following device:
>
> $ ls -la /dev/cuahw0p0
> crw-rw-r-- 1 bin bin 1 0x000015 May 20 06:51
> /dev/cuahw0p0
>
> This device I use in my "Devices" file in /etc/ppp.
>
> Now when I follow my pppd.log I see:
>
> 5/20-07:09:53-1011 Entering stream_ip_open()
> 5/20-07:09:53-1012 Can't open '/etc/ppp/Filter'; all packets are
> significant
> 5/20-07:09:53-1012 Hewlett-Packard PPP
> 5/20-07:09:53-1012 Version 2.0 Beta [2-Jun-1998 20:17:15
> hpux-streams-hppa-export]
> 5/20-07:09:53-1012 du0: pppd hoenow.in-berlin.de~:inberlin auto idle 240
> debug 1
> 5/20-07:14:25-1012 8/0/icmp 192.168.0.22 -> 192.109.42.4 1500 bringup
> 5/20-07:14:25-1012 Can't open 'cuahw0p0': Not a typewriter
> 5/20-07:14:25-1012 Call to 192.109.42.235 failed (Can't open `cuahw0p0':
> Not a typewriter)
>
> The PPP connection does not come up. In my modem initialization string I
> define hardware flow control.
> When using a device file without hardware flow control everything runs
> fine.
> What is missing?
>
> System is a C360, running HP-UX 11.0.
>
> Many thanks in advance, Martin.
>
How do I fax this information?
Hardware Flow Control
Turning on hardware flow control (RTS/CTS) on the port is important in getting the modem to work properly and for best performance. The interface must support hardware flow control to work. There is information available on understanding flow control.
First set up a modem port using sam and let it create the standard device files. The device files will be in the form of
For callin: /dev/ttydIpY For callout /dev/culIpY For hardwired: /dev/cuaIpYwhere I is the instance number and Y is the port on the interface.
You then type : lssf /dev/ttydXpY (with values of X and Y substituted) to get the driver information. For example:
#lssf /dev/ttyd1p0 asio0 card instance 1 callin at address 20/2 /dev/ttyd1p0With this information,
you can create the hardware flow control devices with the following commands:
For all drivers except asio0: mksf -dNote that the appended _rts is a suggested name to indicate the device type has hardware flow control turned on.- I -f -a 2 -p /dev/ttydXpY_rts mksf -d - I -f -a 1 -p /dev/culXpY_rts mksf -d - I -f -a 0 -p /dev/ttydXpY_rts For the asio0 driver (to turn on FIFO): mksf -d -I -f -r 3 -x 3 -a 2 -p /dev/ttydXpY_rts mksf -d -I -f -r 3 -x 3 -a 1 -p /dev/culXpY_rts mksf -d -I -f -r 3 -x 3 -a 0 -p /dev/ttyXpY_rts
For example from the above lssf command:
mksf -d asio0 -I 1 -a 2 -f -r 3 -x 3 -p0 /dev/ttyd1p0_rts mksf -d asio0 -I 1 -a 1 -f -r 3 -x 3 -p0 /dev/cul1p0_rts mksf -d asio0 -I 1 -a 0 -f -r 3 -x 3 -p0 /dev/tty1p0_rts
You now have six device files (with values of X and Y substituted):
Copyright (c) 1996 Hewlett Packard
How do I fax this information?
Callout
This section describes how to set up the system and the modem to either communicate with the modem to program it or to call out to another system.
Most modems will take their incoming computer communication speed at the from the last callout speed so it is vital to set that speed. Therefore, you should give an AT command to the modem at whatever speed you want the getty program to run at otherwise you will get garbage.
Using the hardwired device file with hardware flow control, you should be able to communicate with the modem with the kermit program. While you can use cu as well, kermit requires that fewer files be set up correctly, contains builtin help and its commands are more user friendly. to communicate with the modem, you run kermit as follows:
#kermit
Executing /usr/share/lib/kermit/ckermit.ini for UNIX...
Good Afternoon!
C-Kermit 5A(190), 4 Oct 94, for HP-UX 10.0
Copyright (C) 1985, 1994,
Trustees of Columbia University in the City of New York.
Type ? or HELP for help.
[/root] C-Kermit>set line /dev/ttyXpY_rts
<------Use the hardwired device file with hardware flow control
[/root]C-Kermit> set speed 115200
<------Use the maximum speed of the interface or modem whichever is
less
[/root]C-Kermit> connect
<------connect to port
AT <------Give AT command to modem
OK <------get response
<------ Modem commands can be given here
< CTRL>\ C <------Simultaneously hit CTRL and backslash keys then
hit C to get kermit attention
[/root] C-Kermit>quit
#
Copyright (c) 1996 Hewlett Packard
Updated 8/8/96
How do I fax this information?
WHAT IS FLOW CONTROL?
Whenever serial data is transferred asynchronously, there needs to be a way to control the flow of data so the sender doesn't send information faster than the receiver can handle it. There are basically two types of flow control in use, software and hardware. These terms, as we will see, are misleading and do not necessarily imply that the former is done by programming and the latter by discrete electronic circuitry.
Software Flow Control
Software flow control can more clearly be called character flow control. With software flow control, flow control characters are sent down the same wires that other data is sent. Software flow control
* Is simple * Requires no extra wires * Looks like other data so can be passed through modems
Thus on asynchronous serial lines, only the standard three wires (send, receive, and ground) are required. There are numerous different types of software flow control but the two most common to HP users are Enq/Ack and XON/XOFF.
In traditional HP systems, HP used its own flow control called Enq/Ack.
The sending device would send a block of data and then send an enquiry
character (ASCII CODE 5
Enq/Ack protocol is a positive acknowledgement protocol. If the
receiver fails to send the acknowledgement, no more data is sent.
Therefore, if the printer is turned off or the line is broken, the
computer stops sending. In the world of personal communication, Enq/Ack
could probably be compared to a business not sending any more goods
until the prior goods are paid for. Dunning letters are sent if there
is no response to the first shipment. There are a few problems with
Enq/Ack, principally due to the fact that only HP uses it extensively so
finding third party devices that support it is difficult unless the
products are made for the HP market.
XON/XOFF is another software flow control. With XON/XOFF, the receiver
controls the data as shown in figure 2. When the receiver sends an XOFF
(ASCII CODE 19
Since the receiver knows when it is ready to accept data, it can decide
when to tell the sender to stop and go. The advantage of XON/XOFF is
that it is standard and available on virtually any printer and high
speed modem around. The disadvantage as compared to Enq/Ack is that
there is no way for the sender to know if the receiver ever got the data
as a lack of an XOFF could be due to the ability to handle the data as
fast as it comes or the fact that the decice at the other end is off or
not even connected. In the world of personal communications, XON/XOFF
can be compared to those Record Clubs that continue to send you and bill
you for records unless you send them a postcard saying you don't want
them. You get them even when on vacation or if you no longer live at
that address.
In general, there are other disadvantages to software flow control.
Since the control information looks just like data, it is subjected to
the same problems of data. It may be lost due to
As an alternative to software flow control, there is a technique to use
separate wires along with the serial data to provide independent signals
that control the flow of data. This is commonly referred to as hardware
flow control. Understand that the processing of software flow control
may be equally done in hardware but most people consider hardware flow
control to mean using these separate signal lines. In hardware flow
control, the receiver drops the signal on its control line which tells
the sender to stop until such time as the signal is raised.
The advantages of hardware flow control are twofold
Reliability is due to the fact that a power loss, cable break or other
problem will cause loss of signal, stopping the data. There is no
character to interpret, no confusion with other characters, no parity or
framing.
Because of the simple drop in the signal line, the sender sees the
signal instantly as compared to a full character width in software flow
control. In addition, the circuitry necessary to implement this
stopping, if really done in hardware, is quite simple. Thus for high
data rates, hardware flow control is a much better method of stopping
high speed transfers. Hardware flow control has two major drawbacks.
They are
To implement hardware flow control requires that there be an extra
signal line between sender and receiver for each direction.
Unfortunately, that means that the simple, three wire cable now has to
be five wires. The connectors may be bigger; there may not be wires
available if, for example, four wire phone cable is used. Worse,
standard RS-232 cables have no defined pins for hardware flow control
for bi-directional transfer.
Among the RS-232 signals are Request-to-Send (RTS) and Clear-to-Send
(CTS). The intention of these is to provide hardware flow control to
modems from computers, printers or terminal devices. The computer will
raise RTS when it has data to send and the modem will raise CTS when it
is ready to accept the data as shown in figure 3. These signals have
been used, though,
The result is that we can now use these signals to achieve
bi-directional flow control. There are however some downsides:
* Not all devices support bi-directional use of hardware flow control
* Not all devices use these signals to achieve flow control.
Although many modems support the use of RTS as in figure 4, it is wise
to check that the one you intend to use will do so. Some printers,
especially older ones, don't use these signals and, instead, depend on
being able to raise and lower Data Terminal Ready (DTR) instead of RTS
and thus the DTR signal from the printer has to be wired to the RTS
input of the modem.
Copyright (c) 1996 Hewlett Packard
The requirements for setting up the port in sam are:
Below are shown both GUI and terminal based sam displays of the Add
Modem screen. After adding the modem, sam will display the created
device file names (see below). Make sure you write down or remember the
names as they will be needed for setting up hardware flow control.
To set up a modem on a D class server or Series 700, pick the interface
desired and
the port and set the baud rate to 115200 (for 28.8 modems) or 57600 for
14.4 modems). Note that CCITT must
not be selected.
To set up a modem on a Series 800 with the 5062-3054, pick the interface
desired and set the baud rate to 19200. Note that CCITT must not
be selected.
Once you have selected the port and told sam OK, then
sam will provide you with the three device files used for the port.
Write them down as the names will be needed.
Copyright (c) 1996 Hewlett Packard
Note that with the inner 8 pins (2-9) all the non-CCITT required signals
are present.
The J2484-60010
D Series RJ45 16 port panel for 64 channel mux has 16 10 pin RJ45
female connectors labelled 1 to 16. The wiring for these connectors is engraved
on the back of the panel. There are two connectors, one at each end for
connecting 3 additional panels (to provide up to 64 ports), a J2483-60013
cable from
the J2483-60001 computer interface or an extension cable for panel to panel
connection. On the top, there is a power module (J2483-60010)
connection, a power LED and an
online LED.
The J2485-60010
D Series RS-232 16 port panel for 64 channel mux has 16 25 pin DP25 RS232
female connectors labelled 1 to 16. The wiring for these connectors is engraved
on the back of the panel. There are two connectors, one at each end for
connecting 3 additional panels (to provide up to 64 ports), a J2483-60013
cable from
the J2483-60001 computer interface or an extension cable for panel to panel
connection. On the top, there is a power module (J2483-60010)
connection, a power LED and an
online LED. The ports are standard DTE.
The
D Series RJ45 8 port connector for 8 channel mux has 8 10 pin RJ45
female connectors labelled 1 to 8. There is no panel for this
interface.
If you look at a
rear view of a D Series machine, there are two RS-232 9 pin ports.
The system console is connected to the rightmost port
and a UPS on the other. If there is no UPS, the left port can be used
for a modem. The cpabilities of this port are the same as that of a
Series 700. The port is standard female 9 pin DTE (the same as a PC).
If the Remote Access Card is installed, the UPS port is no longer usable
and the port on the Access Card must be used instead.
The S800 D Series Remote Access Port Card,
if installed, disables the UPS port on
the back of the D Series and changes the hardware address of the
console. The Access port contains a Remote Access Modem connector and a
standard female 9 pin DTE (the same as a PC) port for the UPS or a modem
if there is no UPS. The modem or UPS would go on the bottom connector.
The
Typical Series 700 port core I/O card contains two 9 pin RS-232
connectors. Both ports can be used. They are typically labelled "Port A"
(Port 0) and "Port B" (Port 1). The ports are standard female 9 pin DTE
connections (the same as a PC).
The
Series 800 5062-3054 MDP Panel may be labeled MDP or ADP II. It is used by
the J2094A mux, the A1703-60022 core I/O card and the K Series core I/O with its clearly marked
connection to the MDP.
The panel has 8 DB-25 female connectors with
non-standard wiring. A special cable is needed to
convert the pinouts to standard DTE connections.
All ports support modems at baud rates up to 19200. however, if the
console is on port 0, then port 7 is the Remote Access port and
therefore should not be used for a smart modem.
Copyright (c) 1996 Hewlett Packard
The first step in debugging modem problems is to check the basics -
device files, cable
and modem configuration.
The most seen problems are caused by not having the basics correct.
These should always be checked first.
Patches are critical and no debugging should be done without them.
If a modem has lights, verify that the DTR light (labeled TR) and the
auto-answer (AA) are lit. Hitting a key at the remote end should make
the send light flash. If there is no flashing, the problem is in the
modems.
If a modem is not working at all, a check using cu or kermit to call out
will verify that the connection is at least somewhat working. However,
this doesn t guarantee that the modem will work for incoming
connections, that the getty is set up correctly or that the callin
device file is correct. Callout can be checked with kermit.
A ps -ef command will show a ? in the tty column of a modem getty as
it does not have control of the port. Only when CD is raised will the ?
disappear to be replaced by the port name.
If there is no ? in the tty column when there is no connection, then the
device file is wrong or the modem
is holding Carrier Detect high.
When you dial in and get connected, even if there is no login prompt,
the ? should be replaced by the port name. If not, then the modem is not
raising Carrier Detect or the cable is the problem.
A breakout box or an inline tester that shows all the signals can be
used to help debug problems. When used, some things to look for are:
Check that the modem
incoming speed has been set.
Getting garbage (unintelligible characters) usually has two causes:
This means that the modem is likely trying to talk to the computer at a
different speed than the computer is using. There is no way without
an analyzer to tell for
most modems what speed the modem is trying to communicate to the
computer at. However, it can be set by calling out at the
desired speed. Typically the garbage will look something like:
HP-UX systems, like most UNIX systems default to using 7 bit even parity
whereas most users set their systems to be 8 bit no parity. An
indication that there is a parity mismatch is that the login message
kinda looks like a login but half the characters are garbage.
Typically, it will look like:
instead of:
Fixing this problem is simply a matter of changing the other end to
match that of the HP-UX system. If it is desired to make the HP9000 use
8 bit no parity, then an understanding as to how to create
gettydefs
entries is necessary.
Whenever the user logs off or if the user's programs are abnormally
terminated, the line should be dropped. The user should not see another
"login" prompt. This is important for security reasons. If this is not
occurring, check the following:
2) If this is not the problem, reconnect the modem. Kill the getty
program on the port while watching the modem lights. The DTR Signal should drop modem TR
light (if it exists) should go off temporarily until the getty is
respawned. If not, check the following:
b) There is another process holding the port open. Use the
fuser command on all the ports device files to see if another
process is also using the port.
c) The user's shell can trap the "HANGUP" signal or the user process
running can do internal signal handling and thus trap the signal. To
check for this, try logging on such that a different shell and login
.profile are used and no applications are run.
The MDP muxes use downloadable firmware. If the download fails for any
reason, then no port will work. The program which downloads the firmware
is /sbin/dasetup. It normally is run in
/etc/inittab at bootup with the line
If no ports work, a quick test is to run dasetup with
no parameters. If it returns without error, then the download worked.
If it fails, the error should be obvious. It will likely tell you tha
the download file is missing or the download device file can't be
opened. The first problem is usually caused by someone removing the
files. They are only used at bootup and if someone removes them, the
problem will be noticed only when the system is next booted. The second
problem is caused by loss or change in the device file. check a working
system to see what it should look like
WARNING: If dasetup is run when
there are working ports, it will reset them all, possibly causing
problems with user programs. Make sure either nobody is on the system or
no ports on any panel is in use. There is no easy way
to reset just one panel.
Copyright (c) 1996 Hewlett Packard
On HP-UX, in addition to support of the lock files, three different
device files are used as a method for controlling port access. These
are:
The callout device has a higher priority than the callin one so if a
getty is pending on the port and someone tries to callout, the callout
user will get control.
The callout device file is typically of the form /dev/culXXX.
The hardwired device file is typically of the form /dev/ttyXXX.
When modems are setup, sam will remove the hardwired device file by this
name but add one of ther form /dev/cuaXXX. The cua
device file is left over from the past when modems required two serial
ports, one for autodialing (cua) and one for communicating to
the remote (cul).
There is one known exception to the above problem in that the modem uses
the callout speed as its callin speed. MultiTech modems have the
capability to independently set their callin speed via an internal modem
register.
The /etc/gettdefs file is what is used by the getty programs to
communicate to the serial port to allow users to login. There are a
number of rules for entries in the file
1) Each entry MUST be separated by a blank line. Blank lines are not
permitted within an entry.
2) The # sign is a filed separator, not a comment if encountered within
an entry
3) The parameter names are the same as what is used in stty(1). Look
there for explanations.
4) The parameters specified MUST be in uppercase.
5) For stty, to turn off a parameter you precede it with a minus sign.
In gettydefs, you leave out the parameter. Preceeding the parameter with
a minus is an error resulting in the parameter being ignored (which is
the same as putting it in with a minus).
6) Traditionally modem ports are 7 bit even parity and direct connect
use 8/none. You can change that for modems but UUCP might have problems
with this.
7) You should check the validity of your gettydefs file by
getty -c /etc/gettydefs
The format of an entry is
label # parameters before login # parameters after login # login
prompt # label to use if a BREAK is encountered.
gettydefs(4) has an excellent explanation of the file.
A typical modem showing the signals for which there are LEDs.
Carrier Detect is a signal from the modem.
It indicates whether the
modem has a valid carrier signal from the remote end. It is raised when
carrier is present and lowered when it is not. Modems with LEDs will
typically have a CD light. When a modem drops CD, HP-UX will send a
HANGUP signal (SIGHUP - see signal(5)) to any processes connected to the
port causing them to terminate. This will effectively log the user off
the system.
Data Terminal Ready is a signal from the computer
to the modem to
indicate that the computer is ready to make a connection. The DTR signal
is raised automatically when the device
file is opened. If all the programs associated with a modem port are
terminated, then DTR drops, telling the modem to disconnect from the
other by dropping carrier. Modems with LEDs will typically have a TR
light. If TR is not lit, then the modem should not answer the phone.
Request To Send is a signal from the computer
to the modem that it
is ready to accept data. Along with CTS, this constitutes hardware flow
control. The computer raises RTS when its buffer has
emptied and lowers it when the buffer is full. If the computer does not
have RTS enabled and the modem does, the modem will not send any data to
the computer. Each computer/modem pair independently communicates so if
one pair is using RTS/CTS, then the other pair may or may not. Without some
sort of flow control, the receive buffer of the computer could be
overrun resulting in data loss.
Clear To Send is a signal from the modem to the
computer that it is ready to accept data. Along with RTS, this
constitutes hardware flow control. The modem raises RTS when its buffer
has emptied and lowers it when the buffer is full. If the modem does not
have CTS enabled and the computer does, the computer will not send any
data to the modem. Each computer/modem pair independently communicates
so if one pair is using RTS/CTS, then the other pair may or may not.
Receive Data contains the serial stream of characters received by
the modem from the remote modem and transmitted
to the computer. For each character received, the LED will momentarily
flash. If there is a lot of data at high speed, the LED may appear to be
steadily on.
Transmit Data contains the serial stream of characters received from
the computer and transmitted (sent) to the remote modem. For each
character received, the LED will momentarily flash. If there is a lot of
data at high speed, the LED may appear to be steadily on.
Copyright (c) 1996 Hewlett Packard
Sender Receiver
Data Sent --------------------------------------->
Enquiry Sent ---------------------------------->
<------------------------Acknowledge Returned
Data Sent --------------------------------------->
Enquiry Sent ---------------------------------->
(no acknowledgement)
Enquiry Sent ---------------------------------->
(no acknowledgement)
Enquiry Sent ---------------------------------->
Figure 1 Enq/Ack Protocol
Sender Receiver
Data Sent --------------------------------------->
<------------------------XOFF
(no data)
<------------------------XON
Data Sent --------------------------------------->
<------------------------XOFF
(no data)
Figure 2 XON/XOFF Protocol
* Parity or Framing Errors.
* Weak Signal Levels.
* Confusion with data, particularly binary data.
* Delays due to need to software process the flow character.
* Inability of older transfer protocols such as uucp to deal with it.
Hardware Flow Control
* Reliability
* Speed
* Extra wires are required.
* There are no defined wires available in RS-232 to do bi-directional
flow control.
DTE (COMPUTER) DCE (MODEM)
Raise RTS
Raise CTS
Data Sent --------------------------------------->
Lower CTS
Data Stops
Raise CTS
Data Sent --------------------------------------->
No more data. Lower RTS.
Figure 3 RTS/CTS
for a slightly modified purpose. As shown in figure 4, with some slight
changes, the RTS signal can be used by the computer to tell the modem to
send data and the CTS signal can be used as it was intended, for the
modem to tell the computer to transmit.
DTE (COMPUTER) DCE (MODEM)
Raise CTS
Data Sent --------------------------------------->
Lower CTS
Data Stops
Raise CTS
Data Sent --------------------------------------->
Raise RTS
<------------------------ Data Sent
Lower RTS.
Data Stops
Figure 4 Modified RTS/CTS For Bi-directional Flow Control
How do I fax this information?
Setting Up a Modem wiht SAM
To set up the modem, use sam. It will create the initial device files
for you and set up the getty program on the port. Once that is done,
then the devices will have to be manually modified to do hardware flow
control.
D Class sam GUI
S800 Terminal based sam
sam names for device files
Updated 11/4/97
How do I fax this information?
Computer Interface
This document explains how to set up modems for interfaces that support hardware (RTS/CTS) flow control. This includes:
Modem Cables
There is an
excellent source of cable information
Modem/Interface Speeds
Modem Requirements
This setup applies to virtually any standard 14400 or 28800 modem. The modem should be set up with the following parameters:
Cable Diagrams
40233A - 9000/800 Series Modem cable.
Note: The lines marked by * are typically required for
modems.
This cable is non-symmetrical, and may not work if reversed.
CPU Modem
-------------------------------------------
Gnd 1 ---------- 1 Gnd *
TD 2 <--------- 3 RD *
RD 3 ---------> 2 TD *
RTS 4 <--------- 8 DCD *
DSR 6 ---------> 20 DTR *
GND 7 <--------> 7 GND *
DCD 8 ---------> 4 RTS*
9 <--------- 22 RI
DTR 20 <--------- 6 DSR
RI 22 <--------- 5 CTS*
24542M - 9000/700 Serial Modem cable and D Series 800 internal 9 pin serial ports
Note: This cable is a standard PC 9 <-> 25 modem cable.
The lines marked with * are usually the ones
needed for modem use.
CPU Modem
( DB-9 F DTE ) (DB-25 M DCE)
-------------------------------------------
CD 1 <--------- 8 CD *
RD 2 <--------- 3 RD *
TD 3 ---------> 2 TD *
DTR 4 ---------> 20 DTR *
GND 5 <--------> 7 GND *
DSR 6 ---------- 6 DSR
RTS 7 ---------- 4 RTS*
CTS 8 ---------- 5 CTS*
RI 9 <--------- 22 RI
D Series RJ45 Cable
The
D Series RJ45 to modem cable for 8 or 64 channel mux to a modem requires
only an 8 pin RJ45 connection for non-CCITT connections.
Signal RJ45 Pin DB-25 Pin
Panel End Modem End
Male Connector
DSR 10 6 Not needed
CTS 9 5
CD 8 8
Ground 7 7
TD (SD) 6 2
Ground 5 7
RD 4 3
DTR 3 20
RTS 2 4
RI 1 22 Not needed
D Series Interface to Modem Cable
The J2483-60013 D Series Interface to panel cable is used with the 64
channel mux card. However, you can build a
custom cable up to 300 feet long.
D Series RS-232 DB-25 Cable
The
D Series RS232 to modem cable for 8 or 64 channel mux is a standard
straight through male to male cable. Any straight through cable will
work if the following pins are wired as a minimum.
Signal DB-25 Pin DB-25 Pin
Panel End Modem End
Male Connector Male Connector
TD (SD) 2 2
RD 3 3
RTS 4 4
CTS 5 5
Ground 7 7
CD 8 8
DTR 20 20
Computer Panels
D Series RJ-45 16 port panel
D Series RS-232 16 port panel
D Series 8 channel mux
D Series Builtin RS-232 Port
D Series Remote Access Port
Series 700 port
Series 800 5062-3054 MDP Panel
Updated 8/8/96
How do I fax this information?
Troubleshooting by Steps
Troubleshooting by Problem
Check Basics
#lssf /dev/*XpY /dev/*XpY_rts (with values of X and Y substituted)
The device files used should show
hardware flow control, should be
appropriate for the use desired (callin,
callout or hardwired), and should not show CCITT.
Modem configuration
Modem lights
Callout Work?
ps output for getty
Breakout box or light box.
Modem Doesn't Answer
There are a number of reasons for a modem not answering:
Modem Answers. No Login Prompt
Check the ps output for getty. It
should show the port name when connected.
Modem Answers. Get garbage
x~f`f``~~~x~~x~x~x~x~x~x~x~x~x~x~x~x~x~x~x~
loÓiŸ:
login:
Modem Answers. Login Prompt. No Response
In nearly all cases, this is a problem where the modem has hardware flow
control enabled and the computer does not. The computer sends the login
prompt to the modem because it is not looking for hardware flow control
but the modem will not send anything because it expects RTS to be high
but the computer does not know to set this. Check
Basics. Also make sure that the getty program is using the hardware
Go to top
flow control device file.
User Not Logged Off After Abnormal
Disconnect
Get "Line Problem" when calling out with
cu
This is caused by not using the right device file when calling out with
cu. Using the callin device file instead of the callout one will cause
this problem. Change the /etc/uucp/Devices file to reflect the correct
callout device.
Panel Card Bad?
No Mux Ports Work
There are numerous symptoms of the failure to load firmware into the MDP
mux. They are:
muxi::sysinit:/sbin/dasetup /dev/console 2>&1 # mux init
The firmware files are in /sbin/lib.
crw------- 2 bin bin 193 0x000080 Jul 11 12:38 /dev/mux0
# lssf /dev/mux0
mux2 card instance 0 transparent hardwired at address 10/4/0 /dev/mux0
Updated 8/8/96
How do I fax this information?
Understanding the Device Files
HP-UX uses multiple device files for the same port. This is unique. In
most UNIX systems, there is a problem with port contention for processes
wanting to share a port for dialin and callout. To resolve this, the
programs that use modem ports create a lock file to indicate that the
port is in use. Because the standard getty program doesn't support lock
files, modem ports traditionally use uugetty.
Callin Device file
When a process open the callin device file, the driver raises DTR but does
not grab a port until CD is raised. Therefore, If you try and use stty
against a callin port device, it will hang if CD is not present. The
callin device file, typically the /dev/ttydXXX device file, is
used by the getty process. The Callin device file is the lowest priority
one. This allows getty to always be waiting on a port, yet if someone wants
to use the port for callout, the outgoing process can grab the port and
when CD is raised, the getty will be blocked from responding to it.
Callout Device file
When a process open the callout device file, the driver raises DTR
and grabs control of the port. However, no data transfer occurs until CD
is raised. If you try and use stty against a callout port device, it
will return with the port characteristics but if you try and write to
the port, the data will wait for the CD signal. Callout programs like
cu(1) disable the modem control so they can communicate to the modem to
give the AT commands, then they re-enable modem control and wait for CD.
Hardwired Device file
For terminals or printers where no modem control is required, the
hardwired device is used. It is also useful for talking directly to a
modem to give AT commands or for manually dialing. since modem control
is not being used by the program, it is possible that when the program
is teminated, the modem will not drop its carrier and the connection
will remain active.
The need for Lock Files
Thus for HP-UX, lock files traditionally used for
port contention are not necessary unless two users with the same user id
try to use the port simultaneously.
Once a device type controls the port, devices of higher or lower
priority are locked out. so if a modem port is in use by a callin user,
the callout or hardwired devices are inhibited.
Incoming Modem Baud Rates
When modern modems are set up to answer, they automatically adjust
their incoming speed to match that of the calling modems. Therefore, no
matter what baud rate modem the caller has, the answering modem will
attempt to adjust its speed appropriately. However, this means that the
computer must know what speed the caller is using so it too can set its
speed. to avoid this, modems use a fixed speed to talk to the computer.
However, the modem does not know what speed to use. Therefore most
modems will remember the last callout speed (last speed used when giving
AT commands to it) as the speed to use for callin. The result is that
you must always first connect to the modem at the
desired callin computer speed to set up the modem and then remember to
always callout at this speed.
The difference between getty programs
There are differences in the features of getty and uugetty.
/usr/sbin/getty
/usr/lbin/uucp/uugetty
The gettydefs file
Modem signals
The following is a basic explanation of a few of the appropriate modem
signals used:
Relevant Pages
... The box is a debranded Presario desktop, sold with model number TS-XN0102RS, ... which is occupied by the useless modem and one PCI-E slot. ... Ethernet port. ... useless modem card has line in only. ...
(comp.unix.bsd.freebsd.misc)
... I'm thinking you should only be handling the modem device, ... and not the port in this case. ... when i run it connected to the internal modem port, ... program hangs without any connection being established. ...
(microsoft.public.vb.general.discussion)
... software and physically remove your modem so that you can reboot the system ... with DOS and DOS based Windows.. ... I remember the days going> back to DOS 6.22, when in connecting up a modem, it had to> be set, and sometimes jumpered, for appropriate COM port. ... >> connections), ...
(microsoft.public.windowsxp.basics)
... > I'm thinking you should only be handling the modem device, ... > and not the port in this case. ... > when i run it connected to the internal modem port, ... > program hangs without any connection being established. ...
(microsoft.public.vb.general.discussion)
... What port speed are you ... If it's faster than the modem can stuff bits onto the ... software flow control with these settings. ...
(comp.os.linux.misc)
