[449] in linux-net channel archive
Re: PLIP woes! SLIP answering phone.
daemon@ATHENA.MIT.EDU (Randy Chapman)
Sun Jun 11 18:44:58 1995
Date: Sun, 11 Jun 1995 14:52:57 -0700 (PDT)
From: Randy Chapman <chapman@u.washington.edu>
To: Ken Estes <m-ke0082@SPARKY.CS.NYU.EDU>
Cc: linux-net@vger.rutgers.edu
In-Reply-To: <9506112053.AA15704@SPARKY.CS.NYU.EDU>
What software is running on the 386? With that little ram, I'm assuming
its not Linux? I've heard that the crynwyr drivers are -not-
compatible with Linux plip.... (but i might justas easily be wrong :)
As for your modem:
If it is external, is the autoanswer light on?
If so, try connecting to it and do: ats0=0 (ithink)
Look at /etc/inittab, see if one of the d1,d2 lines got enabled...
--randy
On Sun, 11 Jun 1995, Ken Estes wrote:
>
> I am trying to get a plip line working at home. I did make a post last
> week with this problem but did not see any suggestions. I have two
> computers, a pentium and a 386. The pentium recoginises a plip0
> interface and the 386 a pipl1 (this seems strange, why do they not use
> the same number for printer output?). I have checked both their
> ifconfig and route tables and they seem OK. I just bought a new
> laplink cable (thinking my soldering might be the culprit) but I
> still can not get any pings back from either end. I am totally out of
> ideas (I only have 1.5Meg on the 386 everything else seems to work
> though). Any help would be appreciated.
>
> One other question while I have the attention of some experts. I have
> just started having my computer answer the phone. This is an
> unintended behavior. I wish to make it stop but it seems to answer
> the phone even when there are no daemons running (I have even killed
> things that should never die). I assume that the only explanation is
> that the modem has some software settings which tell it to answer the
> phone. I have run some different software this week so it is possible
> that this software left the modem in an unusual state. Any info on
> what is going on would be interesting.
>
>
> Ken Estes
> (please respond to this address)
>
