I'm wondering if anybody can educate me on what might be happening to
explain the following:

call in via modem to remote site running SCO UNIX 3.2V4.2. (same procedure
in place for years, nothing changed, I'm as sure as I can be)

modems connect, and I get the login prompt
If I just press <ENTER>, I get another login prompt
However, if I type any characters (e.g. root) before pressing ENTER, the
line gets dropped.
It's done this every time today, over at least a dozen attempts.
I even tried calling in from another site-- same result-- so I'm eliminating
my end as the source of the problem.


Now, what's going on here?
getty is watching for login, on the serial port the modem is connected to.
As soon as it sees carrier, it sends out login prompt. ( I think)

Now, if I just press <ENTER> getty is clever enough to notice no keys
entered, so it just sends login again.
As soon as I press at least one key, then <ENTER>, getty calls login. So,
my thinking is that login is responsible for dropping carrier. Just
wondering if that makes any sense to anybody?

Here is the cu session output:

------------------------
# cu -x9 p75
conn(p75)
Device Type ACU wanted
lockname(/usr/spool/uucp/LCK..tty1a)
mlock tty1A succeeded
fixline(5, 9600)
processdev: calling setdevcfg(cu, ACU)
gdial(hayes2400) called
expect: ("")
got it
sendthem (ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M)
expect: (OK^M)
^M^JOK^Mgot it
sendthem (ATDTnnnnnnn^M)
expect: (CONNECT)
^Jtimed out
lockname(/usr/spool/uucp/LCK..tty1a)
lockname(/usr/spool/uucp/LCK..tty1a)
mlock tty1A succeeded
fixline(5, 9600)
processdev: calling setdevcfg(cu, ACU)
gdial(hayes2400) called
expect: ("")
got it
sendthem (ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M)
expect: (OK^M)
ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M^M^JOK^Mgot it
sendthem (ATDTnnnnnnn^M)
expect: (CONNECT)
^J^M^JCONNECTgot it
getto ret 5
ISTRIP cleared
device status for fd=5
F_GETFL=2, iflag=`12005', oflag=`0', cflag=`2275', lflag=`0', line=`0'
cc[0]=`177', [1]=`34', [2]=`10', [3]=`25', [4]=`1', [5]=`0', [6]=`377',
[7]=`377'
call _mode(1)
Connected
_receive started
9600/ARQ
transmit started

p75

p75 login:
p75

p75 login:
p75

p75 login:
p75

p75 login: root

Lost Carrier
call _rcvdead(4)
call _bye(16)

Disconnected
call cleanup(4)
call _mode(0)
#
-----------------------------------
I'm pretty confident we will get this resolved, as soon as someone goes to
the site, thru cycling modem, rio hub, reboot unix, if needs be.

But I would really like to have some understanding of what might be going on
here.

Thanks for any insight/suggestions

Barry






---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.745 / Virus Database: 497 - Release Date: 28/08/2004

"Barry Swane" <bswane@rogers.com> wrote in message
news:_BN_c.217311$UTP.56743@twister01.bloor.is.net .cable.rogers.com...
> I'm wondering if anybody can educate me on what might be happening to
> explain the following:
>
> call in via modem to remote site running SCO UNIX 3.2V4.2. (same
procedure
> in place for years, nothing changed, I'm as sure as I can be)
>
> modems connect, and I get the login prompt
> If I just press <ENTER>, I get another login prompt
> However, if I type any characters (e.g. root) before pressing ENTER, the
> line gets dropped.
> It's done this every time today, over at least a dozen attempts.
> I even tried calling in from another site-- same result-- so I'm
eliminating
> my end as the source of the problem.
>
>
> Now, what's going on here?
> getty is watching for login, on the serial port the modem is connected to.
> As soon as it sees carrier, it sends out login prompt. ( I think)
>
> Now, if I just press <ENTER> getty is clever enough to notice no keys
> entered, so it just sends login again.
> As soon as I press at least one key, then <ENTER>, getty calls login. So,
> my thinking is that login is responsible for dropping carrier. Just
> wondering if that makes any sense to anybody?
>
> Here is the cu session output:
>
> ------------------------
> # cu -x9 p75
> conn(p75)
> Device Type ACU wanted
> lockname(/usr/spool/uucp/LCK..tty1a)
> mlock tty1A succeeded
> fixline(5, 9600)
> processdev: calling setdevcfg(cu, ACU)
> gdial(hayes2400) called
> expect: ("")
> got it
> sendthem (ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M)
> expect: (OK^M)
> ^M^JOK^Mgot it
> sendthem (ATDTnnnnnnn^M)
> expect: (CONNECT)
> ^Jtimed out
> lockname(/usr/spool/uucp/LCK..tty1a)
> lockname(/usr/spool/uucp/LCK..tty1a)
> mlock tty1A succeeded
> fixline(5, 9600)
> processdev: calling setdevcfg(cu, ACU)
> gdial(hayes2400) called
> expect: ("")
> got it
> sendthem (ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M)
> expect: (OK^M)
> ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M^M^JOK^Mgot it
> sendthem (ATDTnnnnnnn^M)
> expect: (CONNECT)
> ^J^M^JCONNECTgot it
> getto ret 5
> ISTRIP cleared
> device status for fd=5
> F_GETFL=2, iflag=`12005', oflag=`0', cflag=`2275', lflag=`0', line=`0'
> cc[0]=`177', [1]=`34', [2]=`10', [3]=`25', [4]=`1', [5]=`0', [6]=`377',
> [7]=`377'
> call _mode(1)
> Connected
> _receive started
> 9600/ARQ
> transmit started
>
> p75
>
> p75 login:
> p75
>
> p75 login:
> p75
>
> p75 login:
> p75
>
> p75 login: root
>
> Lost Carrier
> call _rcvdead(4)
> call _bye(16)
>
> Disconnected
> call cleanup(4)
> call _mode(0)
> #
> -----------------------------------
> I'm pretty confident we will get this resolved, as soon as someone goes to
> the site, thru cycling modem, rio hub, reboot unix, if needs be.
>
> But I would really like to have some understanding of what might be going
on
> here.
>
> Thanks for any insight/suggestions
>
> Barry

A reboot of unix solved this problem-- now behaves normally. So, I guess it
must have either been the serial port getting rebooted, or possibly some
strange setting in stty that got left behind?
I haven't run into this situation before, which is why I posted it, looking
for a theory that might explain what was going on.
In any event, all's well that ends well.

Barry


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.745 / Virus Database: 497 - Release Date: 29/08/2004

In article <PH7%c.374$qD%1.326@news04.bloor.is.net.cable.roge rs.com>,
Barry Swane <bswane@rogers.com> wrote:
>
>"Barry Swane" <bswane@rogers.com> wrote in message
>news:_BN_c.217311$UTP.56743@twister01.bloor.is.ne t.cable.rogers.com...
>> I'm wondering if anybody can educate me on what might be happening to
>> explain the following:
>>
>> call in via modem to remote site running SCO UNIX 3.2V4.2. (same
>procedure
>> in place for years, nothing changed, I'm as sure as I can be)
>>
>> modems connect, and I get the login prompt
>> If I just press <ENTER>, I get another login prompt
>> However, if I type any characters (e.g. root) before pressing ENTER, the
>> line gets dropped.
>> It's done this every time today, over at least a dozen attempts.
>> I even tried calling in from another site-- same result-- so I'm
>eliminating
>> my end as the source of the problem.
>>
>>
>> Now, what's going on here?
>> getty is watching for login, on the serial port the modem is connected to.
>> As soon as it sees carrier, it sends out login prompt. ( I think)
>>
>> Now, if I just press <ENTER> getty is clever enough to notice no keys
>> entered, so it just sends login again.
>> As soon as I press at least one key, then <ENTER>, getty calls login. So,
>> my thinking is that login is responsible for dropping carrier. Just
>> wondering if that makes any sense to anybody?
>>
>> Here is the cu session output:
>>
>> ------------------------
>> # cu -x9 p75
>> conn(p75)
>> Device Type ACU wanted
>> lockname(/usr/spool/uucp/LCK..tty1a)
>> mlock tty1A succeeded
>> fixline(5, 9600)
>> processdev: calling setdevcfg(cu, ACU)
>> gdial(hayes2400) called
>> expect: ("")
>> got it
>> sendthem (ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M)
>> expect: (OK^M)
>> ^M^JOK^Mgot it
>> sendthem (ATDTnnnnnnn^M)
>> expect: (CONNECT)
>> ^Jtimed out
>> lockname(/usr/spool/uucp/LCK..tty1a)
>> lockname(/usr/spool/uucp/LCK..tty1a)
>> mlock tty1A succeeded
>> fixline(5, 9600)
>> processdev: calling setdevcfg(cu, ACU)
>> gdial(hayes2400) called
>> expect: ("")
>> got it
>> sendthem (ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M)
>> expect: (OK^M)
>> ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M^M^JOK^Mgot it
>> sendthem (ATDTnnnnnnn^M)
>> expect: (CONNECT)
>> ^J^M^JCONNECTgot it
>> getto ret 5
>> ISTRIP cleared
>> device status for fd=5
>> F_GETFL=2, iflag=`12005', oflag=`0', cflag=`2275', lflag=`0', line=`0'
>> cc[0]=`177', [1]=`34', [2]=`10', [3]=`25', [4]=`1', [5]=`0', [6]=`377',
>> [7]=`377'
>> call _mode(1)
>> Connected
>> _receive started
>> 9600/ARQ
>> transmit started
>>
>> p75
>>
>> p75 login:
>> p75
>>
>> p75 login:
>> p75
>>
>> p75 login:
>> p75
>>
>> p75 login: root
>>
>> Lost Carrier
>> call _rcvdead(4)
>> call _bye(16)
>>
>> Disconnected
>> call cleanup(4)
>> call _mode(0)
>> #
>> -----------------------------------
>> I'm pretty confident we will get this resolved, as soon as someone goes to
>> the site, thru cycling modem, rio hub, reboot unix, if needs be.
>>
>> But I would really like to have some understanding of what might be going
>on
>> here.
>>
>> Thanks for any insight/suggestions
>>
>> Barry

>A reboot of unix solved this problem-- now behaves normally.
>So, I guess it must have either been the serial port getting
>rebooted, or possibly some strange setting in stty that got left
>behind? I haven't run into this situation before, which is why I
>posted it, looking for a theory that might explain what was going
>on. In any event, all's well that ends well.

I recall something like this from the past. However rebooting
a system shouldn't be required.

At one time one of the initialization strings that happened on
hangup diddle some modem settings.

The best way to handle modems is to set the configuration you want,
write it the modem firmware, and then when the modem disconnects
just issue an ATZ.

Better yet if you have a modem that issues a reset on carrier drop,
you don't have to do anything. I found that was the only truly
100% reliable way of making modii work on an Unixen.

--
Bill Vermillion - bv @ wjv . com

> >> I'm wondering if anybody can educate me on what might be happening to
> >> explain the following:
> >>
> >> call in via modem to remote site running SCO UNIX 3.2V4.2. (same
> >procedure
> >> in place for years, nothing changed, I'm as sure as I can be)
> >>
> >> modems connect, and I get the login prompt
> >> If I just press <ENTER>, I get another login prompt
> >> However, if I type any characters (e.g. root) before pressing ENTER,
the
> >> line gets dropped.
> >> It's done this every time today, over at least a dozen attempts.
> >> I even tried calling in from another site-- same result-- so I'm
> >eliminating
> >> my end as the source of the problem.
> >>
> >>
> >> Now, what's going on here?
> >> getty is watching for login, on the serial port the modem is connected
to.
> >> As soon as it sees carrier, it sends out login prompt. ( I think)
> >>
> >> Now, if I just press <ENTER> getty is clever enough to notice no keys
> >> entered, so it just sends login again.
> >> As soon as I press at least one key, then <ENTER>, getty calls login.
So,
> >> my thinking is that login is responsible for dropping carrier. Just
> >> wondering if that makes any sense to anybody?
> >>
> >> Here is the cu session output:
> >>
> >> ------------------------
> >> # cu -x9 p75
> >> conn(p75)
> >> Device Type ACU wanted
> >> lockname(/usr/spool/uucp/LCK..tty1a)
> >> mlock tty1A succeeded
> >> fixline(5, 9600)
> >> processdev: calling setdevcfg(cu, ACU)
> >> gdial(hayes2400) called
> >> expect: ("")
> >> got it
> >> sendthem (ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M)
> >> expect: (OK^M)
> >> ^M^JOK^Mgot it
> >> sendthem (ATDTnnnnnnn^M)
> >> expect: (CONNECT)
> >> ^Jtimed out
> >> lockname(/usr/spool/uucp/LCK..tty1a)
> >> lockname(/usr/spool/uucp/LCK..tty1a)
> >> mlock tty1A succeeded
> >> fixline(5, 9600)
> >> processdev: calling setdevcfg(cu, ACU)
> >> gdial(hayes2400) called
> >> expect: ("")
> >> got it
> >> sendthem (ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M)
> >> expect: (OK^M)
> >> ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M^M^JOK^Mgot it
> >> sendthem (ATDTnnnnnnn^M)
> >> expect: (CONNECT)
> >> ^J^M^JCONNECTgot it
> >> getto ret 5
> >> ISTRIP cleared
> >> device status for fd=5
> >> F_GETFL=2, iflag=`12005', oflag=`0', cflag=`2275', lflag=`0', line=`0'
> >> cc[0]=`177', [1]=`34', [2]=`10', [3]=`25', [4]=`1', [5]=`0', [6]=`377',
> >> [7]=`377'
> >> call _mode(1)
> >> Connected
> >> _receive started
> >> 9600/ARQ
> >> transmit started
> >>
> >> p75
> >>
> >> p75 login:
> >> p75
> >>
> >> p75 login:
> >> p75
> >>
> >> p75 login:
> >> p75
> >>
> >> p75 login: root
> >>
> >> Lost Carrier
> >> call _rcvdead(4)
> >> call _bye(16)
> >>
> >> Disconnected
> >> call cleanup(4)
> >> call _mode(0)
> >> #
> >> -----------------------------------
> >> I'm pretty confident we will get this resolved, as soon as someone goes
to
> >> the site, thru cycling modem, rio hub, reboot unix, if needs be.
> >>
> >> But I would really like to have some understanding of what might be
going
> >on
> >> here.
> >>
> >> Thanks for any insight/suggestions
> >>
> >> Barry
>
> >A reboot of unix solved this problem-- now behaves normally.
> >So, I guess it must have either been the serial port getting
> >rebooted, or possibly some strange setting in stty that got left
> >behind? I haven't run into this situation before, which is why I
> >posted it, looking for a theory that might explain what was going
> >on. In any event, all's well that ends well.
>
> I recall something like this from the past. However rebooting
> a system shouldn't be required.
>
> At one time one of the initialization strings that happened on
> hangup diddle some modem settings.
>
> The best way to handle modems is to set the configuration you want,
> write it the modem firmware, and then when the modem disconnects
> just issue an ATZ.
>
> Better yet if you have a modem that issues a reset on carrier drop,
> you don't have to do anything. I found that was the only truly
> 100% reliable way of making modii work on an Unixen.
>
> --
> Bill Vermillion - bv @ wjv . com

Thanks for the insight, Bill
I really thought that power cycling the modem might have actually solved
this, but what happened first was the unix reboot-- so, I agree, it
shouldn't have taken a reboot. (I was just curious as to how the reboot
seemed to resolve the issue).
This modem is configured for dial-out, using the old hayes2400 dial script.
This incorporates the &hayes2400 script to set it back up for dial in
This is like this:
&hayes2400 =,-, "" +++\dATQ0H OK\r ATE0T&D2&C1S0=2X4S2=128S19=15 OK\r
ATS0=2Q1\r

So, I gather you are suggesting that I insert the ATZ string into the
&hayes2400 line?

This is a USR SPORTSTER 14400 modem-- I don't think it has the reset on
carrier drop feature -- but I'll have to dig out a manual to check.

Thanks
Barry



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.745 / Virus Database: 497 - Release Date: 30/08/2004

In article <O6m%c.189247$pTn.76583@news01.bloor.is.net.cable. rogers.com>,
Barry Swane <bswane@rogers.com> wrote:
>> >> I'm wondering if anybody can educate me on what might be happening to
>> >> explain the following:
>> >>
>> >> call in via modem to remote site running SCO UNIX 3.2V4.2. (same
>> >procedure
>> >> in place for years, nothing changed, I'm as sure as I can be)
>> >>
>> >> modems connect, and I get the login prompt
>> >> If I just press <ENTER>, I get another login prompt
>> >> However, if I type any characters (e.g. root) before pressing ENTER,
>the
>> >> line gets dropped.
>> >> It's done this every time today, over at least a dozen attempts.
>> >> I even tried calling in from another site-- same result-- so I'm
>> >eliminating
>> >> my end as the source of the problem.
>> >>
>> >>
>> >> Now, what's going on here?
>> >> getty is watching for login, on the serial port the modem is connected
>to.
>> >> As soon as it sees carrier, it sends out login prompt. ( I think)
>> >>
>> >> Now, if I just press <ENTER> getty is clever enough to notice no keys
>> >> entered, so it just sends login again.
>> >> As soon as I press at least one key, then <ENTER>, getty calls login.
>So,
>> >> my thinking is that login is responsible for dropping carrier. Just
>> >> wondering if that makes any sense to anybody?
>> >>
>> >> Here is the cu session output:
>> >>
>> >> ------------------------
>> >> # cu -x9 p75
>> >> conn(p75)
>> >> Device Type ACU wanted
>> >> lockname(/usr/spool/uucp/LCK..tty1a)
>> >> mlock tty1A succeeded
>> >> fixline(5, 9600)
>> >> processdev: calling setdevcfg(cu, ACU)
>> >> gdial(hayes2400) called
>> >> expect: ("")
>> >> got it
>> >> sendthem (ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M)
>> >> expect: (OK^M)
>> >> ^M^JOK^Mgot it
>> >> sendthem (ATDTnnnnnnn^M)
>> >> expect: (CONNECT)
>> >> ^Jtimed out
>> >> lockname(/usr/spool/uucp/LCK..tty1a)
>> >> lockname(/usr/spool/uucp/LCK..tty1a)
>> >> mlock tty1A succeeded
>> >> fixline(5, 9600)
>> >> processdev: calling setdevcfg(cu, ACU)
>> >> gdial(hayes2400) called
>> >> expect: ("")
>> >> got it
>> >> sendthem (ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M)
>> >> expect: (OK^M)
>> >> ATQ0E0T&D2&C1S0=4X4S2=043S19=15^M^M^JOK^Mgot it
>> >> sendthem (ATDTnnnnnnn^M)
>> >> expect: (CONNECT)
>> >> ^J^M^JCONNECTgot it
>> >> getto ret 5
>> >> ISTRIP cleared
>> >> device status for fd=5
>> >> F_GETFL=2, iflag=`12005', oflag=`0', cflag=`2275', lflag=`0', line=`0'
>> >> cc[0]=`177', [1]=`34', [2]=`10', [3]=`25', [4]=`1', [5]=`0', [6]=`377',
>> >> [7]=`377'
>> >> call _mode(1)
>> >> Connected
>> >> _receive started
>> >> 9600/ARQ
>> >> transmit started
>> >>
>> >> p75
>> >>
>> >> p75 login:
>> >> p75
>> >>
>> >> p75 login:
>> >> p75
>> >>
>> >> p75 login:
>> >> p75
>> >>
>> >> p75 login: root
>> >>
>> >> Lost Carrier
>> >> call _rcvdead(4)
>> >> call _bye(16)
>> >>
>> >> Disconnected
>> >> call cleanup(4)
>> >> call _mode(0)
>> >> #
>> >> -----------------------------------
>> >> I'm pretty confident we will get this resolved, as soon as someone goes
>to
>> >> the site, thru cycling modem, rio hub, reboot unix, if needs be.
>> >>
>> >> But I would really like to have some understanding of what might be
>going
>> >on
>> >> here.
>> >>
>> >> Thanks for any insight/suggestions
>> >>
>> >> Barry
>>
>> >A reboot of unix solved this problem-- now behaves normally.
>> >So, I guess it must have either been the serial port getting
>> >rebooted, or possibly some strange setting in stty that got left
>> >behind? I haven't run into this situation before, which is why I
>> >posted it, looking for a theory that might explain what was going
>> >on. In any event, all's well that ends well.
>>
>> I recall something like this from the past. However rebooting
>> a system shouldn't be required.
>>
>> At one time one of the initialization strings that happened on
>> hangup diddle some modem settings.
>>
>> The best way to handle modems is to set the configuration you want,
>> write it the modem firmware, and then when the modem disconnects
>> just issue an ATZ.
>>
>> Better yet if you have a modem that issues a reset on carrier drop,
>> you don't have to do anything. I found that was the only truly
>> 100% reliable way of making modii work on an Unixen.
>>
>> --
>> Bill Vermillion - bv @ wjv . com

>Thanks for the insight, Bill
>I really thought that power cycling the modem might have actually solved
>this, but what happened first was the unix reboot-- so, I agree, it
>shouldn't have taken a reboot. (I was just curious as to how the reboot
>seemed to resolve the issue).
>This modem is configured for dial-out, using the old hayes2400 dial script.
>This incorporates the &hayes2400 script to set it back up for dial in
>This is like this:
>&hayes2400 =,-, "" +++\dATQ0H OK\r ATE0T&D2&C1S0=2X4S2=128S19=15 OK\r
>ATS0=2Q1\r

>So, I gather you are suggesting that I insert the ATZ string into the
>&hayes2400 line?

No. Just set everything you want into the modem, and then save it.
Then the modem should work without that string.

>This is a USR SPORTSTER 14400 modem-- I don't think it has the reset on
>carrier drop feature -- but I'll have to dig out a manual to check.

That is an old modem. And as such I think you are right on not having
a reset on carrier drop.

It's been at least 5 years since I've looked at an SCO dialer
setup. But I do remember setting things so that only ATZ was
in the dialer file.

--
Bill Vermillion - bv @ wjv . com

In article <I3p7Gy.9DL@wjv.com>, Bill Vermillion <bv@wjv.com> wrote:
>In article <O6m%c.189247$pTn.76583@news01.bloor.is.net.cable. rogers.com>,
>Barry Swane <bswane@rogers.com> wrote:

[massive deletion ..]

[following up to my post]

>>So, I gather you are suggesting that I insert the ATZ string into the
>>&hayes2400 line?

>No. Just set everything you want into the modem, and then save it.
>Then the modem should work without that string.

>>This is a USR SPORTSTER 14400 modem-- I don't think it has the
>>reset on carrier drop feature -- but I'll have to dig out a
>>manual to check.

>That is an old modem. And as such I think you are right on not having
>a reset on carrier drop.

>It's been at least 5 years since I've looked at an SCO dialer
>setup. But I do remember setting things so that only ATZ was
>in the dialer file.

I've just checked Tony's site and short search should give
the info you want.

http://aplawrence.com/Bofcusm/2189.html



--
Bill Vermillion - bv @ wjv . com