From owner-freebsd-net Fri Feb 2 15:22:18 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 7F36D37B401 for ; Fri, 2 Feb 2001 15:21:56 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.1) with ESMTP id f12NM7v22833; Fri, 2 Feb 2001 23:22:07 GMT (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.2/8.11.1) with ESMTP id f12NNW606872; Fri, 2 Feb 2001 23:23:32 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102022323.f12NNW606872@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mike Nowlin Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: PPP - CHAP failure after CHAP success??? In-Reply-To: Message from Mike Nowlin of "Fri, 02 Feb 2001 17:41:06 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Feb 2001 23:23:32 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmm, I can't see how this can happen without any previous log lines saying that a chap packet has been received. If this is repeatable, can you try doing a ``show timer'' right after the SUCCESS response has been sent ? If the radius timer wasn't cleared properly this might result, but I can't see how that could happen... > On a recently cvsup'd machine (4.2-S as of two days ago), incoming PPP > w/CHAP via RADIUS has suddenly broken. Basically, RADIUS OK's the > connection, addr info is transferred & approved, everything looks normal, > until after the log line listing myaddr and hisaddr - why is it doing > CHAP again, and what happened to my RADIUS server? README.changes diffs > only mentioned MSCHAPv2 and MPPE changes - disabled both of those, but it > doesn't make any difference. > > --mike > > > Feb 2 16:06:56 rimmer ppp[320]: tun1: Phase: bundle: Authenticate > Feb 2 16:06:56 rimmer ppp[320]: tun1: Phase: deflink: his = none, mine = > CHAP 0x05 > Feb 2 16:06:56 rimmer ppp[320]: tun1: Phase: Chap Output: CHALLENGE > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Input: RESPONSE (16 > bytes from argos) > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Radius: Request sent > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Radius: ACCEPT received > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: MTU 1500 > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: VJ enabled > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: IP 10.99.1.6 > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Netmask > 255.255.255.252 > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Output: SUCCESS > Feb 2 16:06:57 rimmer ppp[320]: tun1: Warning: 10.99.1.6: Cannot > determine ethernet address for proxy ARP > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: lcp -> open > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: bundle: Network > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: FSM: Using "deflink" as a > transport > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change Initial > --> Closed > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: LayerStart. > Feb 2 16:06:57 rimmer > ppp[320]: tun1: IPCP: deflink: SendConfigReq(1) state = Closed > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: IPADDR[6] 10.129.1.2 > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: COMPPROTO[6] 16 VJ slots > with slot compression > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change Closed > --> Req-Sent > Feb 2 16:06:57 rimmer > ppp[320]: tun1: IPCP: deflink: RecvConfigReq(3) state = Req-Sent > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: IPADDR[6] 10.99.1.6 > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: COMPPROTO[6] 16 VJ slots > with slot compression > Feb 2 16:06:57 rimmer > ppp[320]: tun1: IPCP: deflink: SendConfigAck(3) state = Req-Sent > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: IPADDR[6] 10.99.1.6 > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: COMPPROTO[6] 16 VJ slots > with slot compression > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change > Req-Sent --> Ack-Sent > Feb 2 16:06:57 rimmer > ppp[320]: tun1: IPCP: deflink: RecvConfigAck(1) state = Ack-Sent > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: State change > Ack-Sent --> Opened > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: deflink: LayerUp. > Feb 2 16:06:57 rimmer ppp[320]: tun1: IPCP: myaddr 10.129.1.2 hisaddr = > 10.99.1.6 > Feb 2 16:06:57 rimmer ppp[320]: tun1: Warning: 10.99.1.6: Cannot > determine ethernet address for proxy ARP > > ...new stuff starts here - these lines never showed up before..... > > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: radius: No RADIUS servers > specified > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: Chap Output: FAILURE > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: open -> lcp > Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: LayerDown > Feb 2 16:06:57 rimmer > ppp[320]: tun1: LCP: deflink: SendTerminateReq(3) state = Opened > Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Opened > --> Closing > Feb 2 16:06:57 rimmer > ppp[320]: tun1: LCP: deflink: RecvTerminateReq(4) state = Closing > Feb 2 16:06:57 rimmer > ppp[320]: tun1: LCP: deflink: SendTerminateAck(4) state = Closing > Feb 2 16:06:57 rimmer > ppp[320]: tun1: LCP: deflink: RecvTerminateAck(3) state = Closing > Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: LayerFinish > Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Closing > --> Closed > Feb 2 16:06:57 rimmer ppp[320]: tun1: LCP: deflink: State change Closed > --> Initial > Feb 2 16:06:57 rimmer ppp[320]: tun1: Warning: deflink: Unable to set > physical to speed 0 > Feb 2 16:06:57 rimmer ppp[320]: tun1: Phase: deflink: Disconnected! -- 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