On Sun, 17 Mar 2002, Ian P. Thomas wrote:

> On Saturday, March 16, 2002, at 06:50 PM, Frederick Bruckman wrote:
> >>
> >> ipcp-accept-local
> >> ipcp-accept-remote
> >>
> >> 	I don't have a static IP address to put here.  Should I try it with
> >> 0.0.0.0?
> >
> > Since about NetBSD 1.5, you don't need to give anything for the IP
> > address with ipcp-accept-local.

> 	I tried without any IP address, but the debugging info below shows
> that it gives me one anyway.

Of course it does, but the point is, you don't have to specify one.

Where you hoping for an unnumbered link? You can't have that without a
static IP, to which you would set your ethernet interface before
bringing pppd up.

> 	Strangely enough, it only worked this one time.  The rest of the
> times I've attempted to connect with 'demand', it fails during the LCP
> negotiation.
>
> Mar 16 22:05:59 solo pppd[7161]: pppd 2.4.0 started by ipt, uid 1000
> Mar 16 22:05:59 solo pppd[7161]: Using interface ppp0
> Mar 16 22:05:59 solo pppd[7161]: local  IP address 10.64.64.64
> Mar 16 22:05:59 solo pppd[7161]: remote IP address 10.112.112.112
> Mar 16 22:06:10 solo pppd[7161]: Starting link
> Mar 16 22:06:54 solo pppd[7161]: Serial connection established.
> Mar 16 22:06:54 solo pppd[7161]: Connect: ppp0 <--> /dev/tty00
> Mar 16 22:06:54 solo pppd[7161]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
> <magic 0x327680cb> <pcomp> <accomp>]
> Mar 16 22:06:54 solo pppd[7161]: Modem hangup
> Mar 16 22:06:54 solo pppd[7161]: Connection terminated.
> Mar 16 22:07:23 solo pppd[7161]: Terminating on signal 15.
> Mar 16 22:07:23 solo pppd[7161]: Exit.

So it's *intermittent*, and thus can't be a problem with your "pppd"
options. This seems to be a problem with the modem connection. It
might well seem to connect without pppd because you're not really
sending any traffic. As soon as you start to send traffic, one end or
the other sees errors and tries to retrain. [This serves modem and
server manufacturers well, because naive users love the high initial
connect speed, and aren't usually aware of the immediate retrain.] The
server and the "pppd" only see a long pause. TCP/IP is pretty robust
against that, but the initial phases are not.

Some modems have diagnostics that while let you see what's happening,
and some don't. Check your documentation. The solution, in any case,
is always to lower your maximum connect speed, turn off compression,
or whatever magic the docs say to try when you have trouble
connecting. Sometimes, you just have to try another modem. My "Zoom",
which is great from home, won't hold a connection through my PBX at
work under any circumstances, but an old Practical Peripherals V.32
throttled down to 19200 can stay connected all day, every day.

Frederick