From owner-freebsd-net Mon Apr 2 4:32:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 7E67037B71E for ; Mon, 2 Apr 2001 04:32:43 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f32BWj820416; Mon, 2 Apr 2001 12:32:45 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f32Baae29702; Mon, 2 Apr 2001 12:36:36 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200104021136.f32Baae29702@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Jose M. Alcaide" Cc: net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: user-ppp problems In-Reply-To: Message from "Jose M. Alcaide" of "Sat, 31 Mar 2001 17:46:51 +0200." <3AC5FBEB.E2F09D80@we.lc.ehu.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Apr 2001 12:36:35 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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 // jose@we.lc.ehu.es // jmas@FreeBSD.org ****** > ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein ** [.....] -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message