> Hello,
>
> Some days ago I began to suffer strange problems with user-ppp
> while trying to connect with one specific ISP. For example,
> sometimes the connection fails to establish and the following
> messages are logged:
>
> ...
> tun0: Phase: bundle: Authenticate
> tun0: Phase: deflink: his = CHAP 0x05, mine = none
> tun0: Phase: Chap Input: CHALLENGE (16 bytes from AccEuskaltel)
> tun0: Phase: Chap Output: RESPONSE (**************)
> tun0: LCP: deflink: RecvEchoRequest(1) state = Opened
> tun0: LCP: deflink: SendEchoReply(1) state = Opened
> tun0: IPCP: deflink: Error: Unexpected IPCP in phase Authenticate (ignored)
> last message repeated 3 times
> tun0: LCP: deflink: RecvEchoRequest(2) state = Opened
> tun0: LCP: deflink: SendEchoReply(2) state = Opened
> tun0: IPCP: deflink: Error: Unexpected IPCP in phase Authenticate (ignored)
> last message repeated 3 times
> tun0: LCP: deflink: RecvEchoRequest(3) state = Opened
> tun0: LCP: deflink: SendEchoReply(3) state = Opened
> tun0: LCP: deflink: RecvEchoRequest(4) state = Opened
> tun0: LCP: deflink: SendEchoReply(4) state = Opened
> ...
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.
> 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).
> I updated the machine to 4.3-RC a few days ago, so that I borrowed
> /usr/sbin/ppp from other machine still running 4.2-RELEASE (the compat4x
> libraries are installed) and something different happenned, indeed:
> while using 4.2R's ppp, I got these messages after the connection
> was established:
>
> ...
> tun0: Error: ip_Input: deflink: wrote 52, got Address family not supported by
>protocol family
> tun0: Error: ip_Input: deflink: wrote 532, got Address family not supported by
>protocol family
> last message repeated 3 times
> tun0: Error: ip_Input: deflink: wrote 412, got Address family not supported by
>protocol family
> tun0: Error: ip_Input: deflink: wrote 532, got Address family not supported by
>protocol family
> tun0: Error: ip_Input: deflink: wrote 532, got Address family not supported by
>protocol family
> ...
>
> The IPCP negotiation succeeds. However, a ping to the other end of the P-P
> link does not work. OTOH, the "RecvEchoRequest" and "SendEchoReply"
> messages are still being logged.
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
that a newer version of ppp has been run on. You could try using
something like ``ppp -unit 100 blah'' to get around the problem
(assuming the old version of ppp is new enough to understand -unit).
> I suspect that something was broken in the ISP, so I would like to
> be able to diagnose this problem before calling to their "support"
> people (they don't know that there are other OS apart from Win**ws).
>
> Any ideas?
>
> [I am sending attached the full log of a failed connection]
>
> -- JMA
> ****** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] ******
> ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein **
[.....]
--
Brian <[EMAIL PROTECTED]> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
