Date: Wed, 18 Mar 1998 07:37:24 +0000 From: Brian Somers <brian@Awfulhak.org> To: "Nate Williams" <nate@sneezy.sri.com> Cc: Brian Somers <brian@Awfulhak.org>, Stephen Wynne <stevemw@northwest.com>, stable@FreeBSD.ORG Subject: Re: On-demand dynamic PPP not doing default route correctly Message-ID: <199803180737.HAA00550@awfulhak.org> In-Reply-To: Your message of "Tue, 17 Mar 1998 02:43:25 MST." <199803170943.CAA00552@nomad.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Hmm, that seemed to do the 'routing' trick for sure. *MUCH* better than
> > > having to futz with the routing. However, I don't know what's happening
> > > with the link getting all balled up, since I'm not sure whose fault it
> > > is.
> >
> > The rationale behind the ppp.linkup bit is that ppp doesn't know
> > where your default route should point 'till it negotiates an IP with
> > the other side.
>
> So why doesn't it wait to se the default route until after it knows the
> other side? It seems silly to set something that you know ahead of time
> is bous.
Because in -auto mode, we need a default route through tun interface
so that we can `detect traffic'.
I think the argument is that ppp should cache all the add/delete
options and apply them everytime the interface IP is changed. I'm
considering doing this in the MP version....
> The ``add default HISADDR'' will do this. Ppp
> > doesn't cache these ``add'' and ``delete'' commands and re-apply them
> > when the interface addresses change (which I believe pppd does with
> > the ``defaultroute'' config option). Therefore, the ppp.linkup file
> > must have them.
>
> IMHO, routing shouldn't be necessary in ppp.linkup. What previously
> only required editing one file now requires editing two, thus
> increasing the complexity (un-necessarily).
Ppp always behaved this way. It was always necessary to ``add 0 0
HISADDR'' after the link comes up with a dynamic IP. But I agree,
it's not the intuitive way.
Routing errors and failures used to be logged to the TCP/IP log -
nobody ever got to see them. The only thing that has changed in this
area is that -ddial and -dedicated modes don't configure the
interface when they read the `set ifaddr' line - only -auto mode does
this (as it always has).
> > > Thanks alot for the routing information. It's certainly made life
> > > easier for me!
> >
> > As far as the link jamming is concerned, lqr and ECHO lqr now works
> > properly (well, for me anyway). While re-organising it in the MP
> > branch, I discovered what the problem has been all these years :-)
> >
> > You may want to
> >
> > enable lqr
> > set log +lqm
>
> OK. What am I looking for?
If the peer agrees LQR, enable the lqm logging (below). You'll see
loads of numbers come back. RFC 1333 (at the bottom of page 12)
describes all the things you can deduce from this info. At some
stage I'll get ppp to make some calculations and be a bit more
friendly in its reporting.
If the peer denies LQR, ppp sends ECHO LQR packets instead. These do
not need to be negotiated and are essentially pings - more than 5
without a reply means a disconnect.
> > or if you're in interactive mode (or on a diagnostic socket)
> >
> > set log local +lqm
> >
> > You should see if the other side is silently drifting into oblivion.
> > It's also worth doing the occasional ``show hdlc'' to see if you're
> > getting FCS errors - lots of them may mean you've got a login: prompt
> > at the other end :-(
>
>
> The link shouldn't ever work if I'm seeing a login prompt. My problem
I was thinking along the lines of the ISPs ppp giving up and spawning
a getty without dropping the link.
> is that it works for 15-60 messages (using fetchmail) then jams.
> However, this morning it jammed doing downloads, so I can now say that
> it appears to jam with about anything, but randomly.
>
> (It jammped 3 times in the 4 minutes I took to answer this.)
Sounds wonderful :-( My ISP does this all the time for one of the
phone numbers they publish, *and* they refuse LQR. The other phone
number works fine. I'm not ruling out the fact that there may be
some obscure problem with ppp - but when this happens for me, the
peer just starts to slow down and die. Sometimes it'll wake up again
- giving me ping turnarounds of more than 60 seconds... They (my
ISP) won't talk to me about it (and I'm changing ISPs at the moment).
> Nate
--
Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org>
<http://www.Awfulhak.org>;
Don't _EVER_ lose your sense of humour....
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803180737.HAA00550>