Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DTR Drops After Connect

2 views
Skip to first unread message

Lucky Leavell

unread,
Jun 23, 2003, 8:00:00 PM6/23/03
to comp.unix.sco.misc
OS: OSR5.0.6a
Modem: MultiTech MT2834ZDX (latest firmware rev)
Port: COM1

I received a call last week from a client whose support modem was no longer
working, asking if I would return their MT2834ZDX modem which I had brought
back to the office to check out and see if it needed returning for service.

First, I changed the modem settings to match theirs and asked MultiTech to
make sure they could dial in and get a login prompt which they had no
problem doing on my system. However, when I installed the modem on their
system, it would disconnect immediately after connecting. After trying
everything I could think of, I made another trip with another MT2834ZDX and
spare serial cable. Both modems and serial cables gave the same result as
did a generic modem they had been using. MultiTech tech support was able to
establish a connection between the two whereby we were able to echo
characters back and forth which satisfied them the cable and serial port
were functioning properly. (They set &d0 to force the modem to ignore DTR so
we could stay connected long enough to do anything.)

The other symptoms were the following error
messages on the console when attempting a dial in:

/etc/getty -t60 tty1A m (date_time stamp): Bad speed

INIT: Commands respawning too rapidly ...
id: Se1A: "/etc/getty -t60 tty1A m"

I perused Tony Lawrence's sight and gleaned several suggestions which I
tried today:

Checked the inittab and gettydefs for duplicates and spaces
following the gettydef label, blank lines, etc, port ownership,
Devices file entries and did succeed in getting rid of the
respawning message; the Bad speed message and disconnect problem
persist. I also restored the inittab and gettydefs files from
copies saved before any editing was done (but not from installation
media which was recommended in one TA).

I also checked the TAs but they didn't seem to add anything to Tony's info.

(The 9600 speed and gettydef label was specified by their application vendor
so I did not feel free to try one for hardware flow control.)

inittab lines:

Se1a:234:respawn:/etc/getty tty1a m
Se1A:234:respawn:/etc/getty tty1A m

gettydefs entry:

m # B9600 HUPCL # B9600 CS8 SANE HUPCL TAB3 ECHOE #\r\nlogin: # m

Devices file entries:

ACU tty1A - 9600 MultiModem_MT2834ZDX
Direct tty1a - 9600 direct

/usr/lib/uucp/default/MultiModem_MT2834ZDX:
#
# Vendor: MultiTech_Systems
# Modem : MultiModem MT2834ZDX
#
MDM_SETUP=AT &F E0 Q1 S0=1 S25=20&E4&E1
MDM_SPEAKER=ATM0
MDM_DIALCMD=ATDT
MDM_HANGUP=ATH

and, last but not least, the modem settings (atL5L6L7):

B1 E1 M1 Q2 R0 V1 X0 &E1 &E5 &E6 &E8 &E10 &E12 &E14 %C0 #C1 &C4 L3
$MB9600 $SB9600 $BA0 &W0

S0 S2 S3 S4 S5 S6 S7 S8 S9 S10 S13 S24 S25 S30
001 043 013 010 008 002 045 002 006 007 037 020 000 000

$A0 #A0 &B0 &BS1 $D0 &D2 %DL0 %DC0 %E1 %E4 #F2 $F0 &G0 #L0
&P0 &Q0 $R0 &R1 &RF1 &S1 &SF0 &T5 $T1 $V0 $V6 #V1 Y0
$MB9600 $SB9600 $BA0 &W0

(These values were transcribed and therefore subject to
transcription errors)

I did try setting &C1 (from &C4) to no avail.)

Can anyone point out what I am missing here?
(ANY suggestions will be greatly appreciated.)

Thank you,
Lucky

Lucky Leavell Phone: (800) 481-2393 (US/Canada)
UniXpress - Your Source for SCO OR: (812) 366-4066
1560 Zoar Church Road NE FAX: (812) 366-3618
Corydon, IN 47112-7374 Email: lu...@UniXpress.com
WWW Home Page: http://www.UniXpress.com

James J

unread,
Jun 24, 2003, 12:44:26 AM6/24/03
to
Lucky Leavell <lu...@unixpress.com> expounded in
news:Pine.SC5.4.10.103062...@ris.UniXpress.com:

[snipped]

I didn't go over all of it in detail, but that's wrong. You don't want to
enable both tty1a and tty1A.

James

Bill Campbell

unread,
Jun 24, 2003, 1:48:37 AM6/24/03
to Sco Mailing List
On Tue, Jun 24, 2003 at 04:44:26AM +0000, James J wrote:
>Lucky Leavell <lu...@unixpress.com> expounded in
>news:Pine.SC5.4.10.103062...@ris.UniXpress.com:
>
>> OS: OSR5.0.6a
>> Modem: MultiTech MT2834ZDX (latest firmware rev)
>> Port: COM1
>>
>> I received a call last week from a client whose support modem was no
>> longer working, asking if I would return their MT2834ZDX modem which I
>> had brought back to the office to check out and see if it needed
>> returning for service.

I don't remember the details, and don't have a MultiTech manual handy, but
do remember a similar problem using HylaFAX. I'm using this string to
initialize the modem ``AT&D3S25=2'' which sets it so DTR resets, and the
S25=2 is the trick that sets a timer to allow it to connect without
dropping the line.

Bill
--
INTERNET: bi...@Celestial.COM Bill Campbell; Celestial Software LLC
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/

Once at a social gathering, Gladstone said to Disraeli, ``I predict,
Sir, that you will die either by hanging or of some vile disease''.
Disraeli replied, "That all depends upon whether I embrace your
principles or your mistress".

Rick Peters

unread,
Jun 24, 2003, 2:42:22 PM6/24/03
to
Why are you enabling both the modem control version and the 3 wire
(Rx,Tx,GND) version of the same port ?
The control lines will be set to strange states and what ever else.
"Lucky Leavell" <lu...@unixpress.com> wrote in message
news:Pine.SC5.4.10.103062...@ris.UniXpress.com...

Lucky Leavell

unread,
Jun 24, 2003, 9:33:23 PM6/24/03
to Rick Peters, comp.unix.sco.misc
On Tue, 24 Jun 2003, Rick Peters wrote:

> Why are you enabling both the modem control version and the 3 wire
> (Rx,Tx,GND) version of the same port ?
> The control lines will be set to strange states and what ever else.

I am not sure how this happened; I DO know to enable the upper case one
and disable the lower case one and the problem manifested itself with
the ports so set.

I received a call today from MultiTech's SCO guy who indicated there was a
problem with 5.0.6 and told me how to work around it. I will try his
suggestions tomorrow and post them here if they work.

John DuBois

unread,
Jun 25, 2003, 4:45:08 PM6/25/03
to
In article <Pine.SC5.4.10.103062...@ris.UniXpress.com>,

Lucky Leavell <lu...@unixpress.com> wrote:
>OS: OSR5.0.6a
>Modem: MultiTech MT2834ZDX (latest firmware rev)
>Port: COM1
>
>The other symptoms were the following error
>messages on the console when attempting a dial in:
>
> /etc/getty -t60 tty1A m (date_time stamp): Bad speed
>
> INIT: Commands respawning too rapidly ...
> id: Se1A: "/etc/getty -t60 tty1A m"
>
...

>(The 9600 speed and gettydef label was specified by their application vendor
>so I did not feel free to try one for hardware flow control.)
>
>inittab lines:
>
> Se1a:234:respawn:/etc/getty tty1a m
> Se1A:234:respawn:/etc/getty tty1A m
>
>gettydefs entry:
>
> m # B9600 HUPCL # B9600 CS8 SANE HUPCL TAB3 ECHOE #\r\nlogin: # m
>
>Devices file entries:
>
> ACU tty1A - 9600 MultiModem_MT2834ZDX
> Direct tty1a - 9600 direct
...

>Can anyone point out what I am missing here?
>(ANY suggestions will be greatly appreciated.)

"Bad speed" indicates that after getty ran the modem dialer to initialize the
line, it found that the serial port Baud rate did not match the rate given for
the gettydefs entry you're using. In general this should only happen if you
use the -f option to getty, but it can also happen if another process is
holding the line open - like another getty. See if you continue to have this
problem if you disable tty1a. If you do, try running the dialer manually with
debugging turned on:

/usr/lib/uucp/MultiModem_MT2834ZDX -x9 -h tty1A 9600

Also do '/etc/fuser /dev/tty1[aA]' to see if anything else has the line open.

John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

Lucky Leavell

unread,
Jun 25, 2003, 10:07:30 PM6/25/03
to comp.unix.sco.misc
Yesterday Steve Marusich of MultiTech Tech Support called concerning
this problem. Steve told me that SOME SCO OSR 5.0.6 systems exhibited this
behavior, namely DTR drops as soon as the modems connect. This is the
solution to the problem:

1. Disable both lower and upper case variants for the port
2. Go into the SCOAdmin Modem Manager and set up the upper case
variant up for dial in (in my case, I had to Add Modem)
3. Edit the /usr/lib/uucp/Devices file, commenting out the
ACU entries for the upper case port variant
4. Enable the upper case port

I was back at my client site this afternoon where I followed Steve's
suggestions and the dial in works fine now!

David Font

unread,
Jun 26, 2003, 10:09:37 PM6/26/03
to
This is interesting.

For the last 12 months, I have been trying to convince SCO (via my SCO
Partner) of a similar problem in OSR506 where I get a remote 506 user to
execute the 'ct' command to perform a dialup to the modem on my SCO system.

Quite often the modems get to CONNECT stage and then immediately DISCONNECT.
The remote 506 session running 'ct' hangs in the process.

I have to get the remote user to go through a messy process of running a
script at an alternate console session which will identify the process
number in the LCK file and any associated child processes and then kill
them, then disable and enable the modem TTY before doing the 'ct' again
(which may work OK the next time)

The 'ct' will only execute if there is a ACU entry in the uucp Devices.

OSR506 was the first system where I had to use the SCO 'atdialer' program.
Prior to that I had been successfully using a 'C' dialer program for 8
years, inherited from XENIX and successfully used up to OSR505.

I thought it may have been the initialisation strings used by the atdialer
program. While I was able to improve the success rate through incremental
changes to the initialisation strings, I still get about 30% failure rate. I
then lost faith in the atdialer program and just put up with the
inconvenience it causes.

I have passed on your message to my SCO Partner to investigate further,
perhaps now it cant be ignored or fobbed off.

Dave

"Lucky Leavell" <sco...@unixpress.com> wrote in message
news:Pine.UW2.4.21.030625...@ris7.UniXpress.com...

Jean-Pierre Radley

unread,
Jun 26, 2003, 10:39:07 PM6/26/03
to
David Font typed (on Fri, Jun 27, 2003 at 02:09:37PM +1200):

| I thought it may have been the initialisation strings used by the atdialer
| program. While I was able to improve the success rate through incremental
| changes to the initialisation strings, I still get about 30% failure rate. I
| then lost faith in the atdialer program and just put up with the
| inconvenience it causes.

I set up my modems with &c1&d3, and whatever I want for s0.
My atdialer script never has more in it than:

MDM_SETUP=atz

--
JP

Lucky Leavell

unread,
Jun 27, 2003, 8:21:48 AM6/27/03
to Jean-Pierre Radley, comp.unix.sco.misc

I also changed the /usr/lib/uucp/default/MultiModem_MT2834ZDX file
MDM_SETUP line to match yours (based on a previous c.u.s.m message).

However, if I have the ACU entry commented out in /usr/lib/uucp/Devices,
will this ever be used? (I also set &C1&D3&W0 after observing that the
modem still reflected whatever settings the Modem Manager changed it to; a
simple ATZ reset the modem to my previous settings.)

David Font

unread,
Jun 29, 2003, 10:12:56 PM6/29/03
to

"Jean-Pierre Radley" <j...@jpr.com> wrote in message
news:2003062702...@jpradley.jpr.com...

This is my dialer script from /usr/lib/uucp/default. One difference is I use
&d2

MDM_SETUP=AT&FTL0&D2&C1S0=2S2=043X3E1&W0
MDM_OPTION=
MDM_DIALCMD=ATDT
MDM_ESCAPE=+++
MDM_HANGUP=ATH0
MDM_RESET=ATQ0Z
MDM_DIALIN=ATS0=2
MDM_ATTN=AT
MDM_DSBLESC=ATS2=128
RTC_OK=OK
RTC_NOCARR=NO CARRIER
RTC_ERROR=ERROR
RTC_NOTONE=NO DIALTONE
RTC_BUSY=BUSY
RTC_NOANS=NO ANSWER
RTC_50=not used
RTC_75=not used
RTC_110=not used
RTC_200=not used
RTC_300=CONNECT
RTC_600=not used
RTC_1200=CONNECT 1200
RTC_1800=not used
RTC_2400=CONNECT 2400
RTC_4800=CONNECT 4800
RTC_9600=CONNECT 9600
RTC_19200=CONNECT 19200
RTC_38400=CONNECT 38400


0 new messages