Mgetty & Linux PPP-2.2.0a

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

In article <9510200811.AA29457@San-Jose.ate.slb.com>
Basie Etukudo <basie@San-Jose.ate.slb.com> wrote:

> First, I'm running Slackware 2.3 with Kernel 1.2.13, GVC 14.4K modem
> which has worked excellently with mgetty, ppp-2.2.0a and mgetty-099.

> Now, when I try to make a ppp connection with another system on the
> net, the modem dials and begins negotiating the modem-to-modem
> connection and in the process, the negotiation is dropped.
> Debugging the problem, I observed that the modem lock file in
> /var/spool/uucp has the process ID of mgetty instead of the process
> ID of the ppp chat script.

I don't know your explicit configuration, but in ppp 2.2 (the one I
use) the chat-program does not do any locking but the pppd does and
the pppd runs a script calling chat (with the option "connect" of
pppd).  The pppd does not lock in /var/spool/uucp but in /var/lock as
declared in ppp-2.2/pppd/sys-linux.c (if you didn't change this).

> My suspicion seems to be that mgetty may be interfering with the ppp
> call. Maybe I'm wrong, but with other versions of ppp, the process
> ID in the lock file is that of the chat program.

If your pppd locks in /var/lock and mgetty locks in /var/spool/uucp so
you may have some trouble...
Change the locking-Path in pppd or create a link /var/lock->/var/spool/uucp 
or (best idea but much work to do) recompile all your binaries working
on the serial ports to use /var/lock for their lockfiles as proposed
in the Linux-filesystem-standard 1.2, like I did two weeks ago (here's
the list of the binaries I had to recompile, cause forgetting one of
them causes much trouble: mgetty+sendfax, uucp, ifcico, minicom,
kermit, seyon, ppp, dip).

> Has anyone else seen this problem?

I had this problem, before synchronising the lock-paths.

Ciao

        Roland

-- 
  * Internet: roland@spinnaker.rhein.de * Fido: 2:2450/111.13 *