On Fri, 5 Mar 1999, Linux Lists wrote:
|I have a customer using Linux / mgetty / pppd, who has a very odd
|situation: sometimes some of his modems will just stop answering the
|calls.
|
|After further investigation, I found out what is happening. Sometimes when
|a user hangs up, pppd does _not_ go down. It seems as if it lost the
|SIGHUP signal, which is generated when DCD goes down (which should happen
|as soon as the dialer client hangs up). As pppd didn't die, init does not
|call a new mgetty, and the line is virtually locked, until pppd on that
|port is killed manually. If you kill the "useless" pppd manually, init
|call a new mgetty and eveything is normal again.
Here's a clip from Al Longyear's faq:
For dial-in connections, did you exec the pppd process properly?
The pppd process should be execed from the script rather than
simply executed. If you attempt to simply run the pppd process then
it will be the shell which will receive the SIGHUP hangup signal
and not the pppd process.
The shell script should have a format similar to the following:
#!/bin/sh
exec pppd -detach modem ...
The use of dip and diald has, on occasion, interfered with the
ability of pppd to sense the loss of the carrier. In this case, you
should use the lcp-echo-request and lcp-echo-failure options to
detect the loss of the connection in-band.
---
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]
