Date: Sun, 2 Aug 1998 11:07:36 +0200 (MEST) From: Martin Husemann <martin@rumolt.teuto.de> To: marc@bowtie.nl Cc: hm@hcs.de, freebsd-isdn@FreeBSD.ORG Subject: Re: Tracing Kernel code (isppp) & possible isdnd bug Message-ID: <199808020907.LAA02461@rumolt.teuto.de> In-Reply-To: <199808010825.KAA17791@bowtie.nl> from "Marc van Kempen" at Aug 1, 98 10:25:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
> This sounds an awful lot like my problem, I was just going to ask here how to > trace a problem like this. I'll include my sppp debug output for starters, [..] > Aug 1 10:01:05 schopenhauer /kernel: isppp0: phase network > Aug 1 10:01:05 schopenhauer /kernel: isppp0: ipcp open(stopped) > Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp close(opened) > Aug 1 10:01:05 schopenhauer /kernel: isppp0: phase terminate > Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp output <term-req id=0x32 len=4> > Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp input(closing): <term-ack id=0x2 len=4> > Aug 1 10:01:05 schopenhauer /kernel: isppp0: phase dead > Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp down(closed) > Aug 1 10:01:05 schopenhauer /kernel: isppp0: Down event (carrier loss) This is no ISDN level bug. The connection is coming up, but the lcp state machine decides to go to state "close" when ipcp goes to "open". This is wrong. The rest shows the normal way of disconnecting after lcp enters "close" state. So: the bug is on our side (there is no "lcp input..." logged that would cause a change to "close"), and it's not in the ISDN related stuff. Looks like an isppp bug to me. Time to hunt... Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808020907.LAA02461>