-BEGIN PGP SIGNED MESSAGE-
Well, actually the manual isn't wrong. AT&F does reset the modem but to
FACTORY DEFAULTS. ATZ re-initializes the modem to the prior settings. If
the factory sets the defaults to no compression, no error checking, and
software handshaking for example and minico
-BEGIN PGP SIGNED MESSAGE-
It's my understanding that /dev/cua* is outdated and only used for backward
compatability. /dev/ttyS* is the correct usage. Which both belong to
dialout.
On 11-Apr-97 Greg Vence wrote:
>Rob Browning wrote:
>>
>> "Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes:
>
Greg Vence <[EMAIL PROTECTED]> writes:
> Please don't let me start another editor snowball here. What is the
> difference between /dev/ttyS0 and /dev/cua0?
I think this is (or should be) a FAQ somewhere, but the short story is
that the cua* devices are only kept around in the kernel for
historic
Rob Browning wrote:
>
> "Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes:
>
> > You mean the modem device or something else? I am using /dev/modem which
> > is symlinked to /dev/ttyS1 in pppd as well minicom and pppupd both of
> > which redial correctly.
>
> I may be mistaken, but I think that this
"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes:
> You mean the modem device or something else? I am using /dev/modem which
> is symlinked to /dev/ttyS1 in pppd as well minicom and pppupd both of
> which redial correctly.
I may be mistaken, but I think that this can cause problems in some
cases, esp
On Fri, 11 Apr 1997, Jaldhar H. Vyas wrote:
>
> A weird thing is happening to my pppd. (version 2.2.0f-19) I added the
> persist option to /etc/ppp/options so that if the connection went down, it
> would immediately be brought back up again. However what happens is it
> attempts to dial and the
On Fri, 11 Apr 1997, Rick wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
> Why don't you try adding a wait or sleep command to the chatscript just
> before the dialout, or try a comma (,) between the numbers to see if it
> helps. It may be just sending the data too fast.
>
> Also. Normally at&f
On Fri, 11 Apr 1997, Dave Cinege wrote:
> I'm seeing things like this once and awhile. I just went to a serial port
> that only provides Rx, Tx, RTS, and CTS.
>
> I have to set DTR ON all the timeon the modem, and it seems to work fine,
> but sometimes it will not redial correctly. It also take
On Fri, 11 Apr 1997, Lawrence Chim wrote:
> Are you using cua for your modem?
>
You mean the modem device or something else? I am using /dev/modem which
is symlinked to /dev/ttyS1 in pppd as well minicom and pppupd both of
which redial correctly.
-- Jaldhar
Are you using cua for your modem?
Jaldhar H. Vyas wrote:
>
> A weird thing is happening to my pppd. (version 2.2.0f-19) I added the
> persist option to /etc/ppp/options so that if the connection went down, it
> would immediately be brought back up again. However what happens is it
> attempts to
On Fri, 11 Apr 1997 01:32:36 -0500 (EST), Jaldhar H. Vyas wrote:
>
>A weird thing is happening to my pppd. (version 2.2.0f-19) I added the
>persist option to /etc/ppp/options so that if the connection went down, it
>would immediately be brought back up again. However what happens is it
>attempts
On Fri, 11 Apr 1997 01:32:36 -0500 (EST), Jaldhar H. Vyas wrote:
>
>A weird thing is happening to my pppd. (version 2.2.0f-19) I added the
>persist option to /etc/ppp/options so that if the connection went down, it
>would immediately be brought back up again. However what happens is it
>attempts
-BEGIN PGP SIGNED MESSAGE-
Why don't you try adding a wait or sleep command to the chatscript just
before the dialout, or try a comma (,) between the numbers to see if it
helps. It may be just sending the data too fast.
Also. Normally at&f doesn't reset the modem. It resets FACTORY DEF
13 matches
Mail list logo
