From owner-freebsd-isdn Tue Jan 5 23:09:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA28069 for freebsd-isdn-outgoing; Tue, 5 Jan 1999 23:09:08 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from linteuto.teuto.de (linteuto.teuto.de [194.77.23.26]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA28064 for ; Tue, 5 Jan 1999 23:09:05 -0800 (PST) (envelope-from martin@rumolt.teuto.de) Received: from rumolt.teuto.de (root@rumolt.teuto.de [212.8.203.81]) by linteuto.teuto.de (8.8.7/8.8.7) with ESMTP id IAA20160; Wed, 6 Jan 1999 08:08:36 +0100 Received: (from martin@localhost) by rumolt.teuto.de (8.8.8/8.8.7) id IAA01930; Wed, 6 Jan 1999 08:04:30 +0100 (MET) From: Martin Husemann Message-Id: <199901060704.IAA01930@rumolt.teuto.de> Subject: Re: HELP: crash with I4B To: balu@dva.in-berlin.de (Boris Staeblow) Date: Wed, 6 Jan 1999 08:04:30 +0100 (MET) Cc: freebsd-isdn@FreeBSD.ORG In-Reply-To: <19990106014154.A2921@dva.in-berlin.de> from "Boris Staeblow" at Jan 6, 99 01:41:54 am Organization: Crusaders Catering Services Inc. ;-) X-Mailer: ELM [version 2.4 PL24] 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 > > Are you using callback with this connection? > > No - it's a simple PPP-connection to my Provider. This is fine as Hellmuth didn't believe me (yet?) that this is not a problem of the immediate-calledback support I've integrated just before the beta was released. > Jan 5 23:56:16 xx /kernel: isp0: phase dead > Jan 5 23:56:16 CHD 00001 xx outgoing call disconnected (remote) > Jan 5 23:56:16 xx /kernel: i4b-L3-i4b_decode_q931: cannot find calldescriptor > for cr = 0x3b, crflag = 0x1, msg = 0x4d, frame = 0x4d 0x8 0x2 0x82 0xd1 This is nearly the same I get: cr 0x3b was a valid cr for CHD 00001 until this connection was disconnected. The correct RELEASE COMPLETE message is sent by i4b: > -- NT->TE - unit:0 - frame:000021 - time:05.01 23:56:16. 26304 - length:8 ------ > Dump:000 02 f3 0a 08 .... > Q921: SAP=0 (Call Control), C, TEI=121, I-Frame: N(S) 5 N(R) 4 P 0 > Dump:004 08 01 bb 5a ...Z > Q931: pd=Q.931/I.451, cr=0x3b (from destination), message=RELEASE COMPLETE: and after this the calldescriptor is destroyed, invalidating this cr from i4b's point of view. Somehow the network does not see the RELEASE COMPLETE (and in my setup I've verified it realy isn't sent to the wire by i4b) and after some short timeout repeats the RELEASE, hoping to get a RELEASE COMPLETE now: > -- NT->TE - unit:0 - frame:000023 - time:05.01 23:56:16.106305 - length:12 ----- > Dump:000 02 f3 0c 08 .... > Q921: SAP=0 (Call Control), C, TEI=121, I-Frame: N(S) 6 N(R) 4 P 0 > Dump:004 08 01 bb 4d 08 02 82 d1 ...M.... > Q931: pd=Q.931/I.451, cr=0x3b (from destination), message=RELEASE: > [cause: 81: Invalid call reference value (Q.850) > (location=public network serving local user, std=CCITT)] But: we don't have the cr any longer, can't find a calldescriptor and shoot ourself in the foot. There are two points here: the cr should be kept around for the timeout period. Not that hard to do. But the real problem: due to some race condition in layer 1 or layer 2 we don't send the release complete, and this has to be debugged first. I'm working on it. Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message