From owner-freebsd-isdn Tue Sep 21 1: 6:49 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from brain.element-5.de (brain.element-5.de [195.185.111.1]) by hub.freebsd.org (Postfix) with ESMTP id F34AB14C30 for ; Tue, 21 Sep 1999 01:06:44 -0700 (PDT) (envelope-from pherman@element-5.de) Received: from mail.element-5.de (mail.element-5.de [195.185.111.25]) by brain.element-5.de (8.9.3/8.9.3) with ESMTP id KAA04310; Tue, 21 Sep 1999 10:06:38 +0200 (CEST) Date: Tue, 21 Sep 1999 10:06:38 +0200 (CEST) From: Paul Herman To: Brian Somers Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: RFC 1661 Loop? (Was Re: if_spppsubr.c) In-Reply-To: <199909201802.TAA00996@keep.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Brian, > It looks like your ISP is requesting LCP options 0x11 (unknown to me) > and 0x13 (callback). When sppp rejects them, it requests them again. In both cases my ISP only requests them once. After sppp rejects them he doesn't ask for them again. *When* it gets stuck, the loop that sppp gets stuck in goes a little sompin like dis: SPPP: (conf-req) "Hi, I want Magic = xxxx" ISP: (conf-req) "Hi, I want PAP, Multilink, and Callback" SPPP: (conf-rej) "Sorry, I don't do Multilink and Callback" ISP: (conf-ack) "Fine by me. I'll do PAP, and Magic = xxxx" SPPP: (conf-ack) "Fine by me. I'll do PAP, and Magic = xxxx" ISP: (conf-ack) "Fine by me. I'll do PAP, and Magic = xxxx" SPPP: (conf-ack) "Fine by me. I'll do PAP, and Magic = xxxx" ISP: (conf-ack) "Fine by me. I'll do PAP, and Magic = xxxx" SPPP: (conf-ack) "Fine by me. I'll do PAP, and Magic = xxxx" Both my ISP and SPPP seem to be in "ack-sent" state, and looking at RFC 1661, if both are in this same "ack-sent" state and all they do is send "conf-acks", then there's no way out of this -- until they just timeout. Like I said, this only happens 1/2 the time. Is this good? I dunno, but it must be something else, because the older code (the old i4b 0.7x days) works with my same provider, no problem. I could of course use 0.7x but it has other problems. Thoughts? Anyone? I'm just chomping at the bit to start digging into the code (already have played around a lot) but I'm stumped on this one. Just need some direction. In the mean time, my boss wants to replace this box with a Linux ISDN box. Staunch diehard I am, I still keep pushing for FreeBSD, but I don't know how long I can hold out... Paul Herman > > ------- When it connects, it connects no problem ----- > > Sep 18 12:10:27 fw2-test /kernel: isp0: lcp open(initial) > > Sep 18 12:10:27 fw2-test /kernel: isp0: phase establish > > Sep 18 12:10:28 fw2-test /kernel: isp0: Up event > > Sep 18 12:10:28 fw2-test /kernel: isp0: lcp up(starting) > > Sep 18 12:10:28 fw2-test /kernel: isp0: lcp output > > Sep 18 12:10:28 fw2-test /kernel: isp0: lcp input(req-sent): > Sep 18 12:10:28 fw2-test /kernel: isp0: lcp parse opts: mru auth-proto lcp/0x13 [rej] send conf-rej > > Sep 18 12:10:28 fw2-test /kernel: isp0: lcp output > > Sep 18 12:10:28 fw2-test /kernel: isp0: lcp input(req-sent): > > Sep 18 12:10:28 fw2-test /kernel: isp0: lcp input(ack-rcvd): > > Sep 18 12:10:29 fw2-test /kernel: isp0: lcp parse opts: mru auth-proto > > Sep 18 12:10:29 fw2-test /kernel: isp0: lcp parse opt values: mru 1524 auth-proto send conf-ack > > Sep 18 12:10:29 fw2-test /kernel: isp0: lcp output > > Sep 18 12:10:29 fw2-test /kernel: isp0: lcp tlu > > Sep 18 12:10:29 fw2-test /kernel: isp0: phase authenticate > > [....snip!....] > > > > ------- When I get problems, it gets stuck in this loop ------ > > Sep 18 12:10:58 fw2-test /kernel: isp0: lcp open(initial) > > Sep 18 12:10:58 fw2-test /kernel: isp0: phase establish > > Sep 18 12:10:59 fw2-test /kernel: isp0: Up event > > Sep 18 12:10:59 fw2-test /kernel: isp0: lcp up(starting) > > Sep 18 12:10:59 fw2-test /kernel: isp0: lcp output > > Sep 18 12:11:01 fw2-test /kernel: isp0: lcp input(req-sent): > Sep 18 12:11:01 fw2-test /kernel: isp0: lcp parse opts: auth-proto magic lcp/0x11 [rej] lcp/0x13 [rej] send conf-rej > > Sep 18 12:11:01 fw2-test /kernel: isp0: lcp output > > Sep 18 12:11:01 fw2-test /kernel: isp0: lcp input(req-sent): > > Sep 18 12:11:01 fw2-test /kernel: isp0: lcp parse opts: auth-proto magic > > Sep 18 12:11:01 fw2-test /kernel: isp0: lcp parse opt values: auth-proto magic 0x32fa3ce send conf-ack > > Sep 18 12:11:01 fw2-test /kernel: isp0: lcp output > > Sep 18 12:11:03 fw2-test /kernel: isp0: lcp input(ack-sent): > > Sep 18 12:11:03 fw2-test /kernel: isp0: lcp parse opts: auth-proto magic > > Sep 18 12:11:03 fw2-test /kernel: isp0: lcp parse opt values: auth-proto magic 0x32fa3ce send conf-ack > > Sep 18 12:11:03 fw2-test /kernel: isp0: lcp output > > Sep 18 12:11:05 fw2-test /kernel: isp0: lcp input(ack-sent): > > Sep 18 12:11:05 fw2-test /kernel: isp0: lcp parse opts: auth-proto magic > > Sep 18 12:11:05 fw2-test /kernel: isp0: lcp parse opt values: auth-proto magic 0x32fa3ce send conf-ack > > Sep 18 12:11:05 fw2-test /kernel: isp0: lcp output > > Sep 18 12:11:07 fw2-test /kernel: isp0: lcp input(ack-sent): > > Sep 18 12:11:07 fw2-test /kernel: isp0: lcp parse opts: auth-proto magic > > > > ...and repeats every 2 seconds until my ISP gives up and hangs up on me. > > > > How could they both get stuck like this? Or even better, what needs to be > > done to get out of this? It happens with my provider (NetCologne) about > > 40% of the time. I have 0.70 running on another box, and have no troubles > > with it. Ideas? Help! I'd like to fix some code! :) > > > > Paul Herman > > Netzwerkadministrator > > -------------------------------------------------------------- _____ 5 > > + element 5 AG - Sachsenring 69 - 50677 Köln - Germany + / _ \ > > + + | <_> | > > + Tel: +49-221-31088-0 Fax: +49-221-31088-99 + | ___/ > > + Mail: pherman@element-5.de WWW: http://www.element-5.de/ + | |__/\ > > -------------------------------------------------------------- \ / > > --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message