On Sat, 17 Apr 1999, Bob Berman wrote:
I've wanted to know the answer to this question for awhile now and your
post spurred me to try to find it. I haven't succeeded fully but did find
out some things about what's happening. It seems to be a pppd problem -
and a dip problem as well.
The first observation is that the cua? device can be used with chat after
using pppd or dip. This is with a 2.1.131 kernel and you still may be able
to use them in 2.2.5 provided support is still present for 2.2.x . The
kernel complains to the /var/log/syslog about using an "obsolete" device
but doesn't prevent the cua? device from being used.
You can also use minicom to get chat to work - at least until the next pppd
runs. Bring up minicom but then immediately exit with alt-q so minicom
doesn't reset. You should be able to use chat without pppd. I *think* this
will happen for most reasonable minicom configurations.
The problem is that apparently neither pppd or dip correctly resets the
serial terminal attributes. You can do "stty -a < /dev/ttySx" to get these
attributes while pppd is connected to your ISP. You can also use stty to
display the attributes after the minicom trick too, without a PPP
connection.
Several of the settings are different in the output of stty for the two
cases, but in particular there is a "clocal" attribute after the minicom
trick but it's "-clocal" during the PPP connection. If you do
"stty -clocal < /dev/ttySx" after the minicom trick then both chat and
subsequent stty commands hang again. You can find brief explanations of
allthe device file settings that stty shows in "man tcsetattr" .
I've taken a brief look at the pppd code but I'm somewhat c challenged and
haven't deciphered it enough to get to the root of the problem. It does
seem highly likely that the -clocal set by pppd for a PPP connection is not
restored to clocal after a pppd connection and that this prevents directly
accessing the device file from the terminal.
|I have Linux 2.2.5, diald 0.99 and all is working fairly well. Before
|this I had Linux 2.0.35, diald 0.16 for a long time. My ppp is now
|2.3.7 also. It used to be 2.2.0f or whatever.
|
|The problem I am encountering is that I would like to dial out on
|my modem from a simple chat script besides via the usual diald method.
|The chat script is for making a non-Internet connection (a beeper).
|
|I can successfully run my chat script at any time prior to connecting
|to the Internet via diald/ppp. After I connect to the Internet, I
|can never communicate to the modem until I reboot again! This includes
|using chat or kermit. The lock file /var/lock/LCK..ttyS1 is present
|during Internet connection, but gone after the link is brought down,
|as expected. Kermit uses the same lock file, and chat uses none.
|I can't even do a simple "echo AT" > /dev/ttyS1.
|
|Now what is keeping the modem "open" or whatever? Is this a diald
|problem or a ppp problem? How do I fix it? Also, after my Internet
|connection goes down, I've noticed that ppp0 doesn't ever disappear
|from "ifconfig -a" output. Under the old system, it used to go away
|after the link went down. Is this maybe keeping the modem open?
|
|Again, the modem is freely available to any program up until I
|do a diald/ppp connection. Then after that, the only thing that
|can ever use the modem again is a subsequent diald/ppp session.
|How can I get diald/ppp to release the modem completely?
---
Clifford Kite Not a guru. (tm)
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
