Brian Somers wrote:
>
> Your chap response isn't getting a success or failure reply, so ppp
> is still in the ``authenticate'' phase -- it's ignoring the IPCP
> packets sent by the peer. I'm not sure why the peer isn't sending
> the success/failure message.
This could explain some recent problems with this particular ISP.
> > Also, I am wondering about the LCP "RecvEchoRequest" and "SendEchoReply"
> > messages. Even when the connection is succesfully established, they
> > keep appearing all the time, _only_ with this specific ISP. I thought
> > that they could be related to LQR, but I disabled and denied LQR in
> > ppp.conf to no avail.
>
> Echo requests must be replied to (well, duplicate echo requests must
> be replied to, but ppp(8) always replies).
Hmmm... But, is there any reason for the peer would be sending those
"pings"? In addition, I started ping(8) on my system while watching
the PPP log, and I noticed that some ICMP replies are delayed
or even lost at the same time the peer sends its "ping". As a consequence,
the overall throughput of TCP connections is seriously -and badly-
affected.
> Sounds like the tun interface is in
> I-want-an-address-family-on-the-front-of-packets mode.
> Unfortunately, later kernels don't reset this flag when the tun
> device is closed, so older versions of ppp won't work on an interface
Uh, oh. I didn't ever thought of a tun(4) behaviour change.
Thanks very much, Brian! Your explanation was very useful.
Cheers,
-- JMA
****** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] ******
** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein **
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
