SEO

g'day folks. i did a google search on the group for my problem and no
luck so i thought i'd post it, maybe some of you tangled with this.
basically, pppd says "/dev/cua00 busy", chat sends "at", expects "ok",
receives nothing, aborts. HOWEVER, minicom on /dev/cua00 works fine, i
can talk to the modem, i can dial, everything. what's even more
frustrating, the pppd conf (/etc/ppp/options, /etc/ppp/isp.chat,
/etc/ppp/peers/isp) are IDENTICAL (in fact are copied over) to the one
on another machine where the modem was previously installed and
worked. since i use a custom kernel on the new machine i thought i
screwed something up and reverted to GENERIC. nada, same problem, pppd
can't do anything with /dev/cua00, minicom has no problem. echo
"atdtXXXXXX\n" > /dev/cua00 makes the modem go off-hook and then
on-hook again (i can hear the line relay clicking twice), which is
normal, i say, since echo can't control the DTR and the modem is set
up to hang up and return to command mode if DTR is low. any ideas?

In article <c80cc499.0410140050.5c821978@posting.google.com >,
andrei tanase <tanase@mail.rdslink.ro> wrote:
>g'day folks. i did a google search on the group for my problem and no
>luck so i thought i'd post it, maybe some of you tangled with this.
>basically, pppd says "/dev/cua00 busy", chat sends "at", expects "ok",
>receives nothing, aborts. HOWEVER, minicom on /dev/cua00 works fine, i
>can talk to the modem, i can dial, everything. what's even more
>frustrating, the pppd conf (/etc/ppp/options, /etc/ppp/isp.chat,
>/etc/ppp/peers/isp) are IDENTICAL (in fact are copied over) to the one
>on another machine where the modem was previously installed and
>worked. since i use a custom kernel on the new machine i thought i
>screwed something up and reverted to GENERIC. nada, same problem, pppd
>can't do anything with /dev/cua00, minicom has no problem. echo
>"atdtXXXXXX\n" > /dev/cua00 makes the modem go off-hook and then
>on-hook again (i can hear the line relay clicking twice), which is
>normal, i say, since echo can't control the DTR and the modem is set
>up to hang up and return to command mode if DTR is low. any ideas?

Hmm ... I don't use ppp at all, but I have some thoughts:

1) Look in /etc/ttys to see whether it is expecting a login
from there. Mine (on a Shuttle SS51G with OpenBSD 3.5) shows:

================================================== ====================
tty00 "/usr/libexec/getty std.9600" unknown off
================================================== ====================

so it is not expecting logins. tty00 is the incoming name for the same
port as cua00 for outgoing. (A ps -ax should not show a getty running
on it. Here is what one look like on a different device:

================================================== ====================
6609 C0 Is+ 0:00.01 /usr/libexec/getty Pc ttyC0
================================================== ====================

I don't know minicom, and don't find it on my system or in the
man pages (perhaps it needs to be installed from the packages?), but
programs like "cu" are designed to gracefully shoulder getty aside (if
the port is not actually in use at that moment) so the same port can be
used for both incoming calls (/dev/ttyxx) and outgoing (/dev/cuaxx).
However, I don't know that pppd is able to do the same.

Another thing which I just spotted in the man page for pppd is
the following:


================================================== ====================
modem_chat
Use the modem control lines during the chat script. The default
is to ignore the state of the CD (Carrier Detect) signal from the
modem during the chat script. If you are using a cua(4) device
(as opposed to a tty(4) device) you should set this option. You
should not use this option with a dialback setup as it will cause
the chat script to exit when carrier drops.
================================================== ====================

Good Luck,
DoN.
--
Email: <dnichols@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

dnichols@d-and-d.com (DoN. Nichols) wrote in message news:<ckmgpp$edv$1@fuego.d-and-d.com>...
>
> 1) Look in /etc/ttys to see whether it is expecting a login
> from there. Mine (on a Shuttle SS51G with OpenBSD 3.5) shows:

no, no getty's running, all ttys disabled, only /dev/console is on

> I don't know minicom, and don't find it on my system or in the
> man pages (perhaps it needs to be installed from the packages?), but
> programs like "cu" are designed to gracefully shoulder getty aside (if
> the port is not actually in use at that moment) so the same port can be
> used for both incoming calls (/dev/ttyxx) and outgoing (/dev/cuaxx).
> However, I don't know that pppd is able to do the same.

yes, minicom is installed from the packages, and yes, cu and tip work
OK.

>
> Another thing which I just spotted in the man page for pppd is
> the following:
>
>
> ================================================== ====================
> modem_chat
> Use the modem control lines during the chat script. The default
> is to ignore the state of the CD (Carrier Detect) signal from the
> modem during the chat script. If you are using a cua(4) device
> (as opposed to a tty(4) device) you should set this option. You
> should not use this option with a dialback setup as it will cause
> the chat script to exit when carrier drops.
> ================================================== ====================
>

i have this in /etc/ppp/options. i tried removing it and using "local"
instead (ie don't use the modem control lines) and now pppd blurts out
"serial line looped back" and dies.

i checked permissions on /dev/cua00 and /dev/tty00, on pppd,
everything seems fine, in fact everything is IDENTICAL to what's on
another machine where the modem works! i suspect a hardware problem
(BIOS settings?) so i'll try to swap modems and see if anything
happens.

In article <c80cc499.0410150037.32d649f7@posting.google.com >,
andrei tanase <tanase@mail.rdslink.ro> wrote:
>dnichols@d-and-d.com (DoN. Nichols) wrote in message news:<ckmgpp$edv$1@fuego.d-and-d.com>...
>>
>> 1) Look in /etc/ttys to see whether it is expecting a login
>> from there. Mine (on a Shuttle SS51G with OpenBSD 3.5) shows:
>
>no, no getty's running, all ttys disabled, only /dev/console is on

O.K.


[ ... ]

>> modem_chat
>> Use the modem control lines during the chat script. The default

[ ... ]

>i have this in /etc/ppp/options. i tried removing it and using "local"
>instead (ie don't use the modem control lines) and now pppd blurts out
>"serial line looped back" and dies.

O.K. Hmm ... does the modem happen to have echoes turned on?
That might account for that message, at least.

>i checked permissions on /dev/cua00 and /dev/tty00, on pppd,
>everything seems fine, in fact everything is IDENTICAL to what's on
>another machine where the modem works! i suspect a hardware problem
>(BIOS settings?) so i'll try to swap modems and see if anything
>happens.

That would be a reasonable test -- and if it *does* work, check
for difference in the modem's configuration -- echoes especially.

Good Luck,
DoN.

--
Email: <dnichols@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

dnichols@d-and-d.com (DoN. Nichols) wrote in message news:<ckplpr$lh1$1@fuego.d-and-d.com>...
>
> That would be a reasonable test -- and if it *does* work, check
> for difference in the modem's configuration -- echoes especially.
>
> Good Luck,
> DoN.

actually it was an \ character in the modem's init string in the chat
script that was unescaped. and initially pppd was started as a daemon
by the rc script with "demand" in /etc/ppp/options but after failing
with "chat script failed" i reverted to the origial configuration of
"pppd call ispX" without removing pppd from the rc script. next boot,
guess what? "/dev/cua00 busy" since pppd without a call or
demand+connect option means dial-in operation, pppd assumes device is
already opened by *getty* (i think?) and LCP requests are present, no
data/carrier/DTR/CTS/whatever -> pppd thinks somebody else is using it
for something else -> device busy. so the problem was an unescaped
backslash and some double bit errors between display and keyboard.

In article <c80cc499.0410172156.1d9112eb@posting.google.com >,
andrei tanase <tanase@mail.rdslink.ro> wrote:
>dnichols@d-and-d.com (DoN. Nichols) wrote in message news:<ckplpr$lh1$1@fuego.d-and-d.com>...
>>
>> That would be a reasonable test -- and if it *does* work, check
>> for difference in the modem's configuration -- echoes especially.
>>
>> Good Luck,
>> DoN.
>
>actually it was an \ character in the modem's init string in the chat
>script that was unescaped. and initially pppd was started as a daemon

Glad that you got it sorted out.

Enjoy,
DoN.

--
Email: <dnichols@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---