RealPort Modems under SCO OpenServer 5.0.6/7

Realport
1

We have 3 SCO machines that are using RealPort(ver 3.0.2f) on a PortServer TS16 (Version 82000854_H) with 12 MultiTech 5656ZDX modems attached (4 ports/modems per machine). The modems work beautifully during light loads of calling out, but during nightly scheduled UUCP polling they begin to go offline one by one.

Below is an example dialog of the symptoms we are seeing after the ports quit responding. This is just using cu to illustrate it. UUCP gets similar results…

Daffy root> cu -x9 com1189
conn(com1189)
Device Type ACU wanted
lockname(/usr/spool/uucp/LCK…ttyc10)
mlock ttyC10 succeeded
fixline(5, 19200)
processdev: calling setdevcfg(cu, ACU)
dialer args :/usr/lib/uucp/MultiTech_MT5656ZDX:-x9:/dev/ttyC10:17852679813:19200
hangup - timeout 15
Sent MODEM <<+++>>-OK
Sent MODEM <>-OK
Sent MODEM <>-OK
MODEM returned <<>>-FAIL no valid response
Sent MODEM <<+++>>-OK
Sent MODEM <>-OK
Sent MODEM <>-OK
MODEM returned <<>>-FAIL no valid response
Sent MODEM <<+++>>-OK
Sent MODEM <>-OK
Sent MODEM <>-OK
MODEM returned <<>>-FAIL no valid response
Sent MODEM <<+++>>-OK
Sent MODEM <>-OK
Sent MODEM <>-OK
MODEM returned <<>>-FAIL no valid response
Sent MODEM <>-OK
MODEM returned <<
Timeout waiting for acu
Dropping DTR
Exit with 136
Forked 10970 Wait got 10970 Status 37777704000
could not connect (timed out)

Here is the info on the port are shown by ditty…
Daffy root> ditty ttyC10
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 50 bufsize 100 edelay 100
-forcedcd fastcook -altpin -fastbaud (9600) -printer
eia232 rtspace -dtrpace ctspace -dsrpace -dcdpace
DTR+ RTS+ CTS+ CD+ DSR- RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; ispeed 9600 baud; ospeed 9600 baud;
-parity hupcl
swtch = ; susp = ;
-inpck -istrip -ixon -opost
-isig -icanon -echo -echoe -echok

I am convinced that it is not actually the modem… as resetting the modem does nothing… Resetting the Portserver does nothing. Rebooting the machine (restarting RealPort) fixes the problem temporarily. We are having to reboot the machines 3 or 4 times each night to get our jobs done. I have tried other models of modems (using the latest available dialers) as well as 2 different PortServer II’s (with the latest firmware) with identical results. I am convinced this is a RealPort problem of some sort. Any ideas?

2

Could you post the complete ditty output for ttyC10? Use syntax: ditty -a /dev/ttyC10

The syntax you listed shows hardware flow control (rtspace ctspace) turned on, which is good. What it doesn’t show is how software flow control is set. If this is turned on as well, that might cause the port to lock in a flow control state it can’t recover from (other than rebooting).

3

Daffy root> ditty -a /dev/ttyC10
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 50 bufsize 100 edelay 100
-forcedcd fastcook -altpin -fastbaud (9600) -printer
eia232 rtspace -dtrpace ctspace -dsrpace -dcdpace
DTR+ RTS+ CTS+ CD+ DSR- RI-
startc = 0x11 stopc = 0x13
-aixon astartc = 0x0 astopc = 0x0
speed 9600 baud; ispeed 9600 baud; ospeed 9600 baud; line = 0(tty);
intr = DEL; quit = ^; erase = ^H; kill = ^U; eof = ^D; eol = ^@;
swtch = ; susp = ; start = ^Q; stop = ^S;
-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk
-ortsfl -ctsflow -rtsflow
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -iuclc
-ixon -ixany -ixoff
-isig -icanon min = 4 time = 0 -xcase -echo -echoe -echok -echonl -noflsh
-iexten -tostop -xclude
-opost -olcuc -onlcr -ocrnl -onocr -onlret -ofill -ofdel
-isscancode
-autoe -ed_emacs -ed_vi -ed_history

4

This may be a bug in the 3.0.2f driver. Try setting: ditty -fastcook /dev/ttyC10.

If that resolves the problem and you want a more permanent solution rather than workaround, remove the 3.0.2f driver and install 3.0.3a instead. It can be downloaded here:

http://support.digi.com/support/drivers/sco_unix/index-portserver.html

5

I’ll give the -fastcook a try tonight and let you know the results tomorrow. Cross your fingers… I know I am. :wink:

6

No dice… still getting the same errors. No noticeable change using -fastcook vs. fastcook.

7

At this point I’d recommend removing the old driver and installing the latest from our website (see link in earlier reply). If that doesn’t resolve this issue, you’ll need to call into Tech Support and create a case for further troubleshooting. Our phone number is 952-912-3456.