From owner-freebsd-isdn Wed Jul 29 23:16:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA09985 for freebsd-isdn-outgoing; Wed, 29 Jul 1998 23:16:47 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA09939 for ; Wed, 29 Jul 1998 23:16:44 -0700 (PDT) (envelope-from andreas@klemm.gtn.com) Received: (from uucp@localhost) by news1.gtn.com (8.8.6/8.8.6) with UUCP id IAA17007; Thu, 30 Jul 1998 08:15:13 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.8/8.8.8) id HAA26675; Thu, 30 Jul 1998 07:55:41 +0200 (CEST) (envelope-from andreas) Message-ID: <19980730075540.A26394@klemm.gtn.com> Date: Thu, 30 Jul 1998 07:55:40 +0200 From: Andreas Klemm To: Stefan Schmidt , Hellmuth Michaelis Cc: isdn@FreeBSD.ORG Subject: Re: something new in current, that might create a leased line ? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: ; from Stefan Schmidt on Wed, Jul 29, 1998 at 10:04:07AM +0200 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jul 29, 1998 at 10:04:07AM +0200, Stefan Schmidt wrote: > Hi, > > > > Stefan Schmidt > > > indicating an "off-by-4 error in i4b_isppp.c around line 600. > > > I don't know which changes he made exactly, but he told me, that > > > after the change the errors went away. > > > > Now it would be nice to know what he did exactly .... > > in i4b/driver/i4b_isppp.c, around line 600, there's some code to prepend > the address family as a four byte field. > > this seems to be unnecessary for -CURRENT. > bpf_mtap( &sc->sc_if, m) works for me. If I change bpf_mtap( &sc->sc_if, &mm) to bpf_mtap( &sc->sc_if, m) the errors go away. -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html "NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Jul 30 02:06:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA04924 for freebsd-isdn-outgoing; Thu, 30 Jul 1998 02:06:06 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA04868 for ; Thu, 30 Jul 1998 02:05:58 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (1711 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Thu, 30 Jul 1998 11:05:37 +0200 (METDST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-26) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m0z1ogr-0000f6C; Thu, 30 Jul 98 11:08 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: bpf_mtap() changes ? (was Re: something new in current ....) In-Reply-To: <19980730075540.A26394@klemm.gtn.com> from Andreas Klemm at "Jul 30, 98 07:55:40 am" To: freebsd-isdn@FreeBSD.ORG (ISDN Mailinglist) Date: Thu, 30 Jul 1998 11:08:01 +0200 (METDST) Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > in i4b/driver/i4b_isppp.c, around line 600, there's some code to prepend > > the address family as a four byte field. > > > > this seems to be unnecessary for -CURRENT. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Can someone with -current bpf knowledge confirm this ? Currently the code looks like this, the attach is done as: bpfattach(&sc->sc_if, DLT_NULL, sizeof(u_int)); and the bpf_mtap call in question currently looks like this: struct mbuf mm; u_int af = AF_INET; mm.m_next = m; mm.m_len = 4; mm.m_data = (char *)⁡ bpf_mtap(&sc->sc_if, &mm); hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Jul 30 07:01:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA06388 for freebsd-isdn-outgoing; Thu, 30 Jul 1998 07:01:18 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA06379 for ; Thu, 30 Jul 1998 07:01:12 -0700 (PDT) (envelope-from heinig@hdz-ima.rwth-aachen.de) Received: from HDZ-IMA.RWTH-Aachen.de (majestix.hdz-ima.RWTH-Aachen.DE) by mail.rwth-aachen.de (PMDF V5.1-10 #30440) with ESMTP id <01J00MYIEI040004O5@mail.rwth-aachen.de> for freebsd-isdn@FreeBSD.ORG; Thu, 30 Jul 1998 16:02:19 +0200 Received: from MAJESTIX/MAIL by HDZ-IMA.RWTH-Aachen.de (Mercury 1.20); Thu, 30 Jul 1998 16:01:34 +0000 Received: from MAIL by MAJESTIX (Mercury 1.20); Thu, 30 Jul 1998 16:01:12 +0000 Received: from hdz-ima.rwth-aachen.de by HDZ-IMA.RWTH-Aachen.de (Mercury 1.20) with ESMTP; Thu, 30 Jul 1998 16:01:07 +0000 Date: Thu, 30 Jul 1998 16:00:30 +0200 From: Gerald Heinig Subject: Tracing Kernel code (isppp) & possible isdnd bug To: hm@hcs.de Cc: ISDN Mailinglist Message-id: <35C07C7E.E57ECB9C@hdz-ima.rwth-aachen.de> MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I've come across a bug in i4b which unfortunately isn't easily reproducible. I've set up my isdnd.rc file for normal dialup operation with the college (no callback & stuff) and instructed isdnd to redial up to 10 times at 5 second intervals. This has worked very well up until the latest alpha release (the current one - I believe it's 10.07.98). I don't think the previous release had this problem, though the more I think about it, the less sure I get... Basically, i4b dials, *seems* to get an active connection and then releases the line about 2 or 3 seconds afterwards. It then re-dials and says it has an active connection, only to release it again after 2-3 seconds and so on, up until 10 tries, when it stops. I've emphasised the "seems" because I'm not actually sure whether the connection could really be established. Our university dialup server gets rather congested after 21:00 hours (until about 00:30 or so) and I've often experienced difficulties getting a port between these times. Those are also the times when I usually come across this problem. At the moment (coming up to 16:00) there's been no problem at all dialing in to college. Now, I'd like to investigate this problem, because it's definitely a bug: (if the line is unavailable, then isdnd's claim about an active connection is false; if the connection really is active, then i4b shouldn't release it without manual intervention). I have a hunch that the problem lies with the ppp code (isppp). My question is: what tools are available for kernel tracing? I'll obviously see whether I can get enough info with isdntrace, but I wouldn't count on it. cheers, Gerald PS. Why do I think isppp is the culprit? Because a kill & restart of isdnd doesn't always solve the problem. PPS. I've just remembered that the "no traffic timeout" behaves erratically as well. It certainly doesn't hang up after 180 seconds of inactivity. I'll double check the outgoing &incoming packets, just to be sure. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Jul 30 07:23:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA09196 for freebsd-isdn-outgoing; Thu, 30 Jul 1998 07:23:56 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from www.scancall.no (www.scancall.no [195.139.183.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA09191 for ; Thu, 30 Jul 1998 07:23:54 -0700 (PDT) (envelope-from Marius.Bendiksen@scancall.no) Received: from super2.langesund.scancall.no [195.139.183.29] by www with smtp id GXSAJIJK; Thu, 30 Jul 98 14:23:50 GMT (PowerWeb version 4.04r6) Message-Id: <3.0.5.32.19980730162235.00914a20@mail.scancall.no> X-Sender: Marius@mail.scancall.no X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 30 Jul 1998 16:22:35 +0200 To: freebsd-isdn@FreeBSD.ORG From: Marius Bendiksen Subject: unexplainable CRC errors Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I recieve crc errors on my FreeBSD box a short while after having hung up a call using my normal phone. A call which has been done by the FBSD system does not produce such an error. The apparatus, cables and the terminal seem unlikely candidates for this problem. Has anyone else experienced this problem? (It is really only a warning, but....) --- Marius Bendiksen, IT-Trainee, ScanCall AS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Jul 30 10:14:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22990 for freebsd-isdn-outgoing; Thu, 30 Jul 1998 10:14:48 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA22985 for ; Thu, 30 Jul 1998 10:14:45 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (1680 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Thu, 30 Jul 1998 16:59:29 +0200 (METDST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-26) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m0z1uDI-0000f6C; Thu, 30 Jul 98 17:01 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: Tracing Kernel code (isppp) & possible isdnd bug In-Reply-To: <35C07C7E.E57ECB9C@hdz-ima.rwth-aachen.de> from Gerald Heinig at "Jul 30, 98 04:00:30 pm" To: heinig@hdz-ima.rwth-aachen.de (Gerald Heinig) Date: Thu, 30 Jul 1998 17:01:52 +0200 (METDST) Cc: freebsd-isdn@FreeBSD.ORG (ISDN Mailinglist) Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From the keyboard of Gerald Heinig: > Basically, i4b dials, *seems* to get an active connection and then releases the > line about 2 or 3 seconds afterwards. It then re-dials and says it has an active > connection, only to release it again after 2-3 seconds and so on, up until 10 > tries, when it stops. I've emphasised the "seems" because I'm not actually sure > whether the connection could really be established. I'd like to see an isdntrace output of this. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Thu Jul 30 14:51:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA03576 for freebsd-isdn-outgoing; Thu, 30 Jul 1998 14:51:34 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA03283 for ; Thu, 30 Jul 1998 14:50:15 -0700 (PDT) (envelope-from heinig@hdz-ima.rwth-aachen.de) Received: from HDZ-IMA.RWTH-Aachen.de (majestix.hdz-ima.RWTH-Aachen.DE) by mail.rwth-aachen.de (PMDF V5.1-10 #30440) with ESMTP id <01J00U23Z8HO00058A@mail.rwth-aachen.de> for freebsd-isdn@freebsd.org; Thu, 30 Jul 1998 19:25:31 +0200 Received: from MAJESTIX/MAIL by HDZ-IMA.RWTH-Aachen.de (Mercury 1.20); Thu, 30 Jul 1998 19:24:31 +0000 Received: from MAIL by MAJESTIX (Mercury 1.20); Thu, 30 Jul 1998 19:24:10 +0000 Received: from hdz-ima.rwth-aachen.de by HDZ-IMA.RWTH-Aachen.de (Mercury 1.20) with ESMTP; Thu, 30 Jul 1998 19:23:59 +0000 Date: Thu, 30 Jul 1998 19:23:21 +0200 From: Gerald Heinig Subject: Re: Tracing Kernel code (isppp) & possible isdnd bug To: hm@hcs.de Cc: ISDN Mailinglist Message-id: <35C0AC09.68829FB5@hdz-ima.rwth-aachen.de> MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) Content-type: multipart/mixed; boundary="------------2D53FFBE0E541E763E7E2DB9" References: Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------2D53FFBE0E541E763E7E2DB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hellmuth Michaelis wrote: > >From the keyboard of Gerald Heinig: > > > Basically, i4b dials, *seems* to get an active connection and then releases the > > line about 2 or 3 seconds afterwards. It then re-dials and says it has an active > > connection, only to release it again after 2-3 seconds and so on, up until 10 > > tries, when it stops. I've emphasised the "seems" because I'm not actually sure > > whether the connection could really be established. > > I'd like to see an isdntrace output of this. > Comin' up.... I'll make a proper effort from now on to get good traces. The one I've attached is one I did more or less out of idle curiosity, but as far as I can remember, the problem came up in this trace. Gerald --------------2D53FFBE0E541E763E7E2DB9 Content-Type: text/plain; charset=us-ascii; name="trace01" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="trace01" =========== isdntrace controller #0 =========== started Sun Jul 26 22:08:32 1998 -- NT->TE - unit:0 - frame:000046 - time:26.07 22:08:34.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000047 - time:26.07 22:08:40.17 - length:4 ---------- Dump:000 02 e1 01 61 ...a Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 48 PF 1 -- TE->NT - unit:0 - frame:000048 - time:26.07 22:08:40.17 - length:4 ---------- Dump:000 02 e1 01 61 ...a Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 48 PF 1 -- NT->TE - unit:0 - frame:000049 - time:26.07 22:08:44.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000050 - time:26.07 22:08:50.17 - length:4 ---------- Dump:000 02 e1 01 61 ...a Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 48 PF 1 -- TE->NT - unit:0 - frame:000051 - time:26.07 22:08:50.17 - length:4 ---------- Dump:000 02 e1 01 61 ...a Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 48 PF 1 -- NT->TE - unit:0 - frame:000052 - time:26.07 22:08:54.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000053 - time:26.07 22:09:00.17 - length:4 ---------- Dump:000 02 e1 01 61 ...a Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 48 PF 1 -- TE->NT - unit:0 - frame:000054 - time:26.07 22:09:00.17 - length:4 ---------- Dump:000 02 e1 01 61 ...a Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 48 PF 1 -- NT->TE - unit:0 - frame:000055 - time:26.07 22:09:04.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000056 - time:26.07 22:09:10.17 - length:4 ---------- Dump:000 02 e1 01 61 ...a Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 48 PF 1 -- TE->NT - unit:0 - frame:000057 - time:26.07 22:09:10.17 - length:4 ---------- Dump:000 02 e1 01 61 ...a Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 48 PF 1 -- NT->TE - unit:0 - frame:000058 - time:26.07 22:09:14.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000059 - time:26.07 22:09:20.17 - length:4 ---------- Dump:000 02 e1 01 61 ...a Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 48 PF 1 -- TE->NT - unit:0 - frame:000060 - time:26.07 22:09:20.17 - length:4 ---------- Dump:000 02 e1 01 61 ...a Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 48 PF 1 -- TE->NT - unit:0 - frame:000061 - time:26.07 22:09:22.39 - length:33 --------- Dump:000 00 e1 60 60 ..`` Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 48 N(R) 48 P 0 Dump:004 08 01 2e 05 a1 04 02 88 90 18 01 81 6c 07 81 36 ............l..6 Dump:020 30 33 33 32 30 70 06 81 38 38 37 32 31 03320p..88721 Q931: pd=Q.931/I.451, cr=0x2e (from origination), message=SETUP: [sending complete] [bearer capability: cap=unrestricted digital information std=CCITT rate=64 kbit/s mode=circuit] [channel id: channel=B-1 (preferred)] [calling party number: 603320 (type=unknown, plan=ISDN)] [called party number: 88721 (type=unknown, plan=ISDN)] -- NT->TE - unit:0 - frame:000062 - time:26.07 22:09:22.41 - length:4 ---------- Dump:000 00 e1 01 62 ...b Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 49 PF 0 -- NT->TE - unit:0 - frame:000063 - time:26.07 22:09:22.73 - length:11 --------- Dump:000 02 e1 60 62 ..`b Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 48 N(R) 49 P 0 Dump:004 08 01 ae 02 18 01 89 ....... Q931: pd=Q.931/I.451, cr=0x2e (from destination), message=CALL PROCEEDING: [channel id: channel=B-1 (exclusive)] -- TE->NT - unit:0 - frame:000064 - time:26.07 22:09:22.73 - length:4 ---------- Dump:000 02 e1 01 62 ...b Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 49 PF 0 -- NT->TE - unit:0 - frame:000065 - time:26.07 22:09:23.19 - length:8 ---------- Dump:000 02 e1 62 62 ..bb Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 49 N(R) 49 P 0 Dump:004 08 01 ae 01 .... Q931: pd=Q.931/I.451, cr=0x2e (from destination), message=ALERTING: -- TE->NT - unit:0 - frame:000066 - time:26.07 22:09:23.19 - length:4 ---------- Dump:000 02 e1 01 64 ...d Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 50 PF 0 -- NT->TE - unit:0 - frame:000067 - time:26.07 22:09:23.28 - length:15 --------- Dump:000 02 e1 64 62 ..db Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 50 N(R) 49 P 0 Dump:004 08 01 ae 07 29 05 62 07 1a 16 08 ....).b.... Q931: pd=Q.931/I.451, cr=0x2e (from destination), message=CONNECT: [date/time: 26.07.98 22:08] -- TE->NT - unit:0 - frame:000068 - time:26.07 22:09:23.28 - length:8 ---------- Dump:000 00 e1 62 66 ..bf Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 49 N(R) 51 P 0 Dump:004 08 01 2e 0f .... Q931: pd=Q.931/I.451, cr=0x2e (from origination), message=CONNECT ACKNOWLEDGE: -- NT->TE - unit:0 - frame:000069 - time:26.07 22:09:23.30 - length:4 ---------- Dump:000 00 e1 01 64 ...d Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 50 PF 0 -- NT->TE - unit:0 - frame:000070 - time:26.07 22:09:24.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000071 - time:26.07 22:09:33.17 - length:4 ---------- Dump:000 02 e1 01 65 ...e Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 50 PF 1 -- TE->NT - unit:0 - frame:000072 - time:26.07 22:09:33.17 - length:4 ---------- Dump:000 02 e1 01 67 ...g Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 51 PF 1 -- NT->TE - unit:0 - frame:000073 - time:26.07 22:09:34.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- TE->NT - unit:0 - frame:000074 - time:26.07 22:09:34.28 - length:12 --------- Dump:000 00 e1 64 66 ..df Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 50 N(R) 51 P 0 Dump:004 08 01 2e 45 08 02 80 90 ...E.... Q931: pd=Q.931/I.451, cr=0x2e (from origination), message=DISCONNECT: [cause: 16: Normal call clearing (Q.850) (location=user, std=CCITT)] -- NT->TE - unit:0 - frame:000075 - time:26.07 22:09:34.29 - length:4 ---------- Dump:000 00 e1 01 66 ...f Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 51 PF 0 -- NT->TE - unit:0 - frame:000076 - time:26.07 22:09:34.42 - length:8 ---------- Dump:000 02 e1 66 66 ..ff Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 51 N(R) 51 P 0 Dump:004 08 01 ae 4d ...M Q931: pd=Q.931/I.451, cr=0x2e (from destination), message=RELEASE: -- TE->NT - unit:0 - frame:000077 - time:26.07 22:09:34.42 - length:8 ---------- Dump:000 00 e1 66 68 ..fh Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 51 N(R) 52 P 0 Dump:004 08 01 2e 5a ...Z Q931: pd=Q.931/I.451, cr=0x2e (from origination), message=RELEASE COMPLETE: -- NT->TE - unit:0 - frame:000078 - time:26.07 22:09:34.43 - length:4 ---------- Dump:000 00 e1 01 68 ...h Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 52 PF 0 -- TE->NT - unit:0 - frame:000079 - time:26.07 22:09:35.05 - length:33 --------- Dump:000 00 e1 68 68 ..hh Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 52 N(R) 52 P 0 Dump:004 08 01 6f 05 a1 04 02 88 90 18 01 81 6c 07 81 36 ..o.........l..6 Dump:020 30 33 33 32 30 70 06 81 38 38 37 32 31 03320p..88721 Q931: pd=Q.931/I.451, cr=0x6f (from origination), message=SETUP: [sending complete] [bearer capability: cap=unrestricted digital information std=CCITT rate=64 kbit/s mode=circuit] [channel id: channel=B-1 (preferred)] [calling party number: 603320 (type=unknown, plan=ISDN)] [called party number: 88721 (type=unknown, plan=ISDN)] -- NT->TE - unit:0 - frame:000080 - time:26.07 22:09:35.07 - length:4 ---------- Dump:000 00 e1 01 6a ...j Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 53 PF 0 -- NT->TE - unit:0 - frame:000081 - time:26.07 22:09:35.40 - length:11 --------- Dump:000 02 e1 68 6a ..hj Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 52 N(R) 53 P 0 Dump:004 08 01 ef 02 18 01 89 ....... Q931: pd=Q.931/I.451, cr=0x6f (from destination), message=CALL PROCEEDING: [channel id: channel=B-1 (exclusive)] -- TE->NT - unit:0 - frame:000082 - time:26.07 22:09:35.40 - length:4 ---------- Dump:000 02 e1 01 6a ...j Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 53 PF 0 -- NT->TE - unit:0 - frame:000083 - time:26.07 22:09:35.84 - length:8 ---------- Dump:000 02 e1 6a 6a ..jj Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 53 N(R) 53 P 0 Dump:004 08 01 ef 01 .... Q931: pd=Q.931/I.451, cr=0x6f (from destination), message=ALERTING: -- TE->NT - unit:0 - frame:000084 - time:26.07 22:09:35.84 - length:4 ---------- Dump:000 02 e1 01 6c ...l Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 54 PF 0 -- NT->TE - unit:0 - frame:000085 - time:26.07 22:09:35.94 - length:15 --------- Dump:000 02 e1 6c 6a ..lj Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 54 N(R) 53 P 0 Dump:004 08 01 ef 07 29 05 62 07 1a 16 08 ....).b.... Q931: pd=Q.931/I.451, cr=0x6f (from destination), message=CONNECT: [date/time: 26.07.98 22:08] -- TE->NT - unit:0 - frame:000086 - time:26.07 22:09:35.94 - length:8 ---------- Dump:000 00 e1 6a 6e ..jn Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 53 N(R) 55 P 0 Dump:004 08 01 6f 0f ..o. Q931: pd=Q.931/I.451, cr=0x6f (from origination), message=CONNECT ACKNOWLEDGE: -- NT->TE - unit:0 - frame:000087 - time:26.07 22:09:35.95 - length:4 ---------- Dump:000 00 e1 01 6c ...l Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 54 PF 0 -- NT->TE - unit:0 - frame:000088 - time:26.07 22:09:44.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000089 - time:26.07 22:09:45.17 - length:4 ---------- Dump:000 02 e1 01 6d ...m Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 54 PF 1 -- TE->NT - unit:0 - frame:000090 - time:26.07 22:09:45.17 - length:4 ---------- Dump:000 02 e1 01 6f ...o Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 55 PF 1 -- TE->NT - unit:0 - frame:000091 - time:26.07 22:09:46.94 - length:12 --------- Dump:000 00 e1 6c 6e ..ln Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 54 N(R) 55 P 0 Dump:004 08 01 6f 45 08 02 80 90 ..oE.... Q931: pd=Q.931/I.451, cr=0x6f (from origination), message=DISCONNECT: [cause: 16: Normal call clearing (Q.850) (location=user, std=CCITT)] -- NT->TE - unit:0 - frame:000092 - time:26.07 22:09:46.95 - length:4 ---------- Dump:000 00 e1 01 6e ...n Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 55 PF 0 -- NT->TE - unit:0 - frame:000093 - time:26.07 22:09:47.06 - length:8 ---------- Dump:000 02 e1 6e 6e ..nn Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 55 N(R) 55 P 0 Dump:004 08 01 ef 4d ...M Q931: pd=Q.931/I.451, cr=0x6f (from destination), message=RELEASE: -- TE->NT - unit:0 - frame:000094 - time:26.07 22:09:47.06 - length:8 ---------- Dump:000 00 e1 6e 70 ..np Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 55 N(R) 56 P 0 Dump:004 08 01 6f 5a ..oZ Q931: pd=Q.931/I.451, cr=0x6f (from origination), message=RELEASE COMPLETE: -- NT->TE - unit:0 - frame:000095 - time:26.07 22:09:47.07 - length:4 ---------- Dump:000 00 e1 01 70 ...p Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 56 PF 0 -- TE->NT - unit:0 - frame:000096 - time:26.07 22:09:47.08 - length:33 --------- Dump:000 00 e1 70 70 ..pp Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 56 N(R) 56 P 0 Dump:004 08 01 31 05 a1 04 02 88 90 18 01 81 6c 07 81 36 ..1.........l..6 Dump:020 30 33 33 32 30 70 06 81 38 38 37 32 31 03320p..88721 Q931: pd=Q.931/I.451, cr=0x31 (from origination), message=SETUP: [sending complete] [bearer capability: cap=unrestricted digital information std=CCITT rate=64 kbit/s mode=circuit] [channel id: channel=B-1 (preferred)] [calling party number: 603320 (type=unknown, plan=ISDN)] [called party number: 88721 (type=unknown, plan=ISDN)] -- NT->TE - unit:0 - frame:000097 - time:26.07 22:09:47.10 - length:4 ---------- Dump:000 00 e1 01 72 ...r Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 57 PF 0 -- NT->TE - unit:0 - frame:000098 - time:26.07 22:09:47.38 - length:11 --------- Dump:000 02 e1 70 72 ..pr Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 56 N(R) 57 P 0 Dump:004 08 01 b1 02 18 01 89 ....... Q931: pd=Q.931/I.451, cr=0x31 (from destination), message=CALL PROCEEDING: [channel id: channel=B-1 (exclusive)] -- TE->NT - unit:0 - frame:000099 - time:26.07 22:09:47.38 - length:4 ---------- Dump:000 02 e1 01 72 ...r Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 57 PF 0 -- NT->TE - unit:0 - frame:000100 - time:26.07 22:09:47.85 - length:8 ---------- Dump:000 02 e1 72 72 ..rr Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 57 N(R) 57 P 0 Dump:004 08 01 b1 01 .... Q931: pd=Q.931/I.451, cr=0x31 (from destination), message=ALERTING: -- TE->NT - unit:0 - frame:000101 - time:26.07 22:09:47.85 - length:4 ---------- Dump:000 02 e1 01 74 ...t Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 58 PF 0 -- NT->TE - unit:0 - frame:000102 - time:26.07 22:09:47.93 - length:15 --------- Dump:000 02 e1 74 72 ..tr Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 58 N(R) 57 P 0 Dump:004 08 01 b1 07 29 05 62 07 1a 16 08 ....).b.... Q931: pd=Q.931/I.451, cr=0x31 (from destination), message=CONNECT: [date/time: 26.07.98 22:08] -- TE->NT - unit:0 - frame:000103 - time:26.07 22:09:47.93 - length:8 ---------- Dump:000 00 e1 72 76 ..rv Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 57 N(R) 59 P 0 Dump:004 08 01 31 0f ..1. Q931: pd=Q.931/I.451, cr=0x31 (from origination), message=CONNECT ACKNOWLEDGE: -- NT->TE - unit:0 - frame:000104 - time:26.07 22:09:47.95 - length:4 ---------- Dump:000 00 e1 01 74 ...t Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 58 PF 0 -- NT->TE - unit:0 - frame:000105 - time:26.07 22:09:54.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000106 - time:26.07 22:09:57.17 - length:4 ---------- Dump:000 02 e1 01 75 ...u Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 58 PF 1 -- TE->NT - unit:0 - frame:000107 - time:26.07 22:09:57.17 - length:4 ---------- Dump:000 02 e1 01 77 ...w Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 59 PF 1 -- TE->NT - unit:0 - frame:000108 - time:26.07 22:09:58.93 - length:12 --------- Dump:000 00 e1 74 76 ..tv Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 58 N(R) 59 P 0 Dump:004 08 01 31 45 08 02 80 90 ..1E.... Q931: pd=Q.931/I.451, cr=0x31 (from origination), message=DISCONNECT: [cause: 16: Normal call clearing (Q.850) (location=user, std=CCITT)] -- NT->TE - unit:0 - frame:000109 - time:26.07 22:09:58.94 - length:4 ---------- Dump:000 00 e1 01 76 ...v Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 59 PF 0 -- NT->TE - unit:0 - frame:000110 - time:26.07 22:09:59.04 - length:8 ---------- Dump:000 02 e1 76 76 ..vv Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 59 N(R) 59 P 0 Dump:004 08 01 b1 4d ...M Q931: pd=Q.931/I.451, cr=0x31 (from destination), message=RELEASE: -- TE->NT - unit:0 - frame:000111 - time:26.07 22:09:59.04 - length:8 ---------- Dump:000 00 e1 76 78 ..vx Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 59 N(R) 60 P 0 Dump:004 08 01 31 5a ..1Z Q931: pd=Q.931/I.451, cr=0x31 (from origination), message=RELEASE COMPLETE: -- NT->TE - unit:0 - frame:000112 - time:26.07 22:09:59.06 - length:4 ---------- Dump:000 00 e1 01 78 ...x Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 60 PF 0 -- NT->TE - unit:0 - frame:000113 - time:26.07 22:10:04.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- TE->NT - unit:0 - frame:000114 - time:26.07 22:10:06.10 - length:33 --------- Dump:000 00 e1 78 78 ..xx Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 60 N(R) 60 P 0 Dump:004 08 01 15 05 a1 04 02 88 90 18 01 81 6c 07 81 36 ............l..6 Dump:020 30 33 33 32 30 70 06 81 38 38 37 32 31 03320p..88721 Q931: pd=Q.931/I.451, cr=0x15 (from origination), message=SETUP: [sending complete] [bearer capability: cap=unrestricted digital information std=CCITT rate=64 kbit/s mode=circuit] [channel id: channel=B-1 (preferred)] [calling party number: 603320 (type=unknown, plan=ISDN)] [called party number: 88721 (type=unknown, plan=ISDN)] -- NT->TE - unit:0 - frame:000115 - time:26.07 22:10:06.12 - length:4 ---------- Dump:000 00 e1 01 7a ...z Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 61 PF 0 -- NT->TE - unit:0 - frame:000116 - time:26.07 22:10:06.40 - length:11 --------- Dump:000 02 e1 78 7a ..xz Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 60 N(R) 61 P 0 Dump:004 08 01 95 02 18 01 89 ....... Q931: pd=Q.931/I.451, cr=0x15 (from destination), message=CALL PROCEEDING: [channel id: channel=B-1 (exclusive)] -- TE->NT - unit:0 - frame:000117 - time:26.07 22:10:06.40 - length:4 ---------- Dump:000 02 e1 01 7a ...z Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 61 PF 0 -- NT->TE - unit:0 - frame:000118 - time:26.07 22:10:06.86 - length:8 ---------- Dump:000 02 e1 7a 7a ..zz Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 61 N(R) 61 P 0 Dump:004 08 01 95 01 .... Q931: pd=Q.931/I.451, cr=0x15 (from destination), message=ALERTING: -- TE->NT - unit:0 - frame:000119 - time:26.07 22:10:06.86 - length:4 ---------- Dump:000 02 e1 01 7c ...| Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 62 PF 0 -- NT->TE - unit:0 - frame:000120 - time:26.07 22:10:06.94 - length:15 --------- Dump:000 02 e1 7c 7a ..|z Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 62 N(R) 61 P 0 Dump:004 08 01 95 07 29 05 62 07 1a 16 09 ....).b.... Q931: pd=Q.931/I.451, cr=0x15 (from destination), message=CONNECT: [date/time: 26.07.98 22:09] -- TE->NT - unit:0 - frame:000121 - time:26.07 22:10:06.94 - length:8 ---------- Dump:000 00 e1 7a 7e ..z~ Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 61 N(R) 63 P 0 Dump:004 08 01 15 0f .... Q931: pd=Q.931/I.451, cr=0x15 (from origination), message=CONNECT ACKNOWLEDGE: -- NT->TE - unit:0 - frame:000122 - time:26.07 22:10:06.96 - length:4 ---------- Dump:000 00 e1 01 7c ...| Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 62 PF 0 -- NT->TE - unit:0 - frame:000123 - time:26.07 22:10:14.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000124 - time:26.07 22:10:16.17 - length:4 ---------- Dump:000 02 e1 01 7d ...} Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 62 PF 1 -- TE->NT - unit:0 - frame:000125 - time:26.07 22:10:16.17 - length:4 ---------- Dump:000 02 e1 01 7f .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 63 PF 1 -- TE->NT - unit:0 - frame:000126 - time:26.07 22:10:17.94 - length:12 --------- Dump:000 00 e1 7c 7e ..|~ Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 62 N(R) 63 P 0 Dump:004 08 01 15 45 08 02 80 90 ...E.... Q931: pd=Q.931/I.451, cr=0x15 (from origination), message=DISCONNECT: [cause: 16: Normal call clearing (Q.850) (location=user, std=CCITT)] -- NT->TE - unit:0 - frame:000127 - time:26.07 22:10:17.95 - length:4 ---------- Dump:000 00 e1 01 7e ...~ Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 63 PF 0 -- NT->TE - unit:0 - frame:000128 - time:26.07 22:10:18.07 - length:8 ---------- Dump:000 02 e1 7e 7e ..~~ Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 63 N(R) 63 P 0 Dump:004 08 01 95 4d ...M Q931: pd=Q.931/I.451, cr=0x15 (from destination), message=RELEASE: -- TE->NT - unit:0 - frame:000129 - time:26.07 22:10:18.07 - length:8 ---------- Dump:000 00 e1 7e 80 ..~. Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 63 N(R) 64 P 0 Dump:004 08 01 15 5a ...Z Q931: pd=Q.931/I.451, cr=0x15 (from origination), message=RELEASE COMPLETE: -- NT->TE - unit:0 - frame:000130 - time:26.07 22:10:18.09 - length:4 ---------- Dump:000 00 e1 01 80 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 64 PF 0 -- TE->NT - unit:0 - frame:000131 - time:26.07 22:10:19.15 - length:33 --------- Dump:000 00 e1 80 80 .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 64 N(R) 64 P 0 Dump:004 08 01 66 05 a1 04 02 88 90 18 01 81 6c 07 81 36 ..f.........l..6 Dump:020 30 33 33 32 30 70 06 81 38 38 37 32 31 03320p..88721 Q931: pd=Q.931/I.451, cr=0x66 (from origination), message=SETUP: [sending complete] [bearer capability: cap=unrestricted digital information std=CCITT rate=64 kbit/s mode=circuit] [channel id: channel=B-1 (preferred)] [calling party number: 603320 (type=unknown, plan=ISDN)] [called party number: 88721 (type=unknown, plan=ISDN)] -- NT->TE - unit:0 - frame:000132 - time:26.07 22:10:19.17 - length:4 ---------- Dump:000 00 e1 01 82 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 65 PF 0 -- NT->TE - unit:0 - frame:000133 - time:26.07 22:10:19.45 - length:11 --------- Dump:000 02 e1 80 82 .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 64 N(R) 65 P 0 Dump:004 08 01 e6 02 18 01 89 ....... Q931: pd=Q.931/I.451, cr=0x66 (from destination), message=CALL PROCEEDING: [channel id: channel=B-1 (exclusive)] -- TE->NT - unit:0 - frame:000134 - time:26.07 22:10:19.45 - length:4 ---------- Dump:000 02 e1 01 82 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 65 PF 0 -- NT->TE - unit:0 - frame:000135 - time:26.07 22:10:20.02 - length:8 ---------- Dump:000 02 e1 82 82 .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 65 N(R) 65 P 0 Dump:004 08 01 e6 01 .... Q931: pd=Q.931/I.451, cr=0x66 (from destination), message=ALERTING: -- TE->NT - unit:0 - frame:000136 - time:26.07 22:10:20.02 - length:4 ---------- Dump:000 02 e1 01 84 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 66 PF 0 -- NT->TE - unit:0 - frame:000137 - time:26.07 22:10:20.11 - length:15 --------- Dump:000 02 e1 84 82 .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 66 N(R) 65 P 0 Dump:004 08 01 e6 07 29 05 62 07 1a 16 09 ....).b.... Q931: pd=Q.931/I.451, cr=0x66 (from destination), message=CONNECT: [date/time: 26.07.98 22:09] -- TE->NT - unit:0 - frame:000138 - time:26.07 22:10:20.11 - length:8 ---------- Dump:000 00 e1 82 86 .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 65 N(R) 67 P 0 Dump:004 08 01 66 0f ..f. Q931: pd=Q.931/I.451, cr=0x66 (from origination), message=CONNECT ACKNOWLEDGE: -- NT->TE - unit:0 - frame:000139 - time:26.07 22:10:20.13 - length:4 ---------- Dump:000 00 e1 01 84 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 66 PF 0 -- NT->TE - unit:0 - frame:000140 - time:26.07 22:10:24.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000141 - time:26.07 22:10:29.17 - length:4 ---------- Dump:000 02 e1 01 85 .... Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 66 PF 1 -- TE->NT - unit:0 - frame:000142 - time:26.07 22:10:29.17 - length:4 ---------- Dump:000 02 e1 01 87 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 67 PF 1 -- TE->NT - unit:0 - frame:000143 - time:26.07 22:10:31.11 - length:12 --------- Dump:000 00 e1 84 86 .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 66 N(R) 67 P 0 Dump:004 08 01 66 45 08 02 80 90 ..fE.... Q931: pd=Q.931/I.451, cr=0x66 (from origination), message=DISCONNECT: [cause: 16: Normal call clearing (Q.850) (location=user, std=CCITT)] -- NT->TE - unit:0 - frame:000144 - time:26.07 22:10:31.12 - length:4 ---------- Dump:000 00 e1 01 86 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 67 PF 0 -- NT->TE - unit:0 - frame:000145 - time:26.07 22:10:31.24 - length:8 ---------- Dump:000 02 e1 86 86 .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 67 N(R) 67 P 0 Dump:004 08 01 e6 4d ...M Q931: pd=Q.931/I.451, cr=0x66 (from destination), message=RELEASE: -- TE->NT - unit:0 - frame:000146 - time:26.07 22:10:31.24 - length:8 ---------- Dump:000 00 e1 86 88 .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 67 N(R) 68 P 0 Dump:004 08 01 66 5a ..fZ Q931: pd=Q.931/I.451, cr=0x66 (from origination), message=RELEASE COMPLETE: -- NT->TE - unit:0 - frame:000147 - time:26.07 22:10:31.25 - length:4 ---------- Dump:000 00 e1 01 88 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 68 PF 0 -- TE->NT - unit:0 - frame:000148 - time:26.07 22:10:32.18 - length:33 --------- Dump:000 00 e1 88 88 .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 68 N(R) 68 P 0 Dump:004 08 01 22 05 a1 04 02 88 90 18 01 81 6c 07 81 36 ..".........l..6 Dump:020 30 33 33 32 30 70 06 81 38 38 37 32 31 03320p..88721 Q931: pd=Q.931/I.451, cr=0x22 (from origination), message=SETUP: [sending complete] [bearer capability: cap=unrestricted digital information std=CCITT rate=64 kbit/s mode=circuit] [channel id: channel=B-1 (preferred)] [calling party number: 603320 (type=unknown, plan=ISDN)] [called party number: 88721 (type=unknown, plan=ISDN)] -- NT->TE - unit:0 - frame:000149 - time:26.07 22:10:32.20 - length:4 ---------- Dump:000 00 e1 01 8a .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 69 PF 0 -- NT->TE - unit:0 - frame:000150 - time:26.07 22:10:32.48 - length:11 --------- Dump:000 02 e1 88 8a .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 68 N(R) 69 P 0 Dump:004 08 01 a2 02 18 01 89 ....... Q931: pd=Q.931/I.451, cr=0x22 (from destination), message=CALL PROCEEDING: [channel id: channel=B-1 (exclusive)] -- TE->NT - unit:0 - frame:000151 - time:26.07 22:10:32.48 - length:4 ---------- Dump:000 02 e1 01 8a .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 69 PF 0 -- NT->TE - unit:0 - frame:000152 - time:26.07 22:10:32.95 - length:8 ---------- Dump:000 02 e1 8a 8a .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 69 N(R) 69 P 0 Dump:004 08 01 a2 01 .... Q931: pd=Q.931/I.451, cr=0x22 (from destination), message=ALERTING: -- TE->NT - unit:0 - frame:000153 - time:26.07 22:10:32.95 - length:4 ---------- Dump:000 02 e1 01 8c .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 70 PF 0 -- NT->TE - unit:0 - frame:000154 - time:26.07 22:10:33.02 - length:15 --------- Dump:000 02 e1 8c 8a .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 70 N(R) 69 P 0 Dump:004 08 01 a2 07 29 05 62 07 1a 16 09 ....).b.... Q931: pd=Q.931/I.451, cr=0x22 (from destination), message=CONNECT: [date/time: 26.07.98 22:09] -- TE->NT - unit:0 - frame:000155 - time:26.07 22:10:33.02 - length:8 ---------- Dump:000 00 e1 8a 8e .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 69 N(R) 71 P 0 Dump:004 08 01 22 0f ..". Q931: pd=Q.931/I.451, cr=0x22 (from origination), message=CONNECT ACKNOWLEDGE: -- NT->TE - unit:0 - frame:000156 - time:26.07 22:10:33.04 - length:4 ---------- Dump:000 00 e1 01 8c .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 70 PF 0 -- NT->TE - unit:0 - frame:000157 - time:26.07 22:10:34.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- TE->NT - unit:0 - frame:000158 - time:26.07 22:10:40.12 - length:12 --------- Dump:000 00 e1 8c 8e .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 70 N(R) 71 P 0 Dump:004 08 01 22 45 08 02 80 90 .."E.... Q931: pd=Q.931/I.451, cr=0x22 (from origination), message=DISCONNECT: [cause: 16: Normal call clearing (Q.850) (location=user, std=CCITT)] -- NT->TE - unit:0 - frame:000159 - time:26.07 22:10:40.13 - length:4 ---------- Dump:000 00 e1 01 8e .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 71 PF 0 -- NT->TE - unit:0 - frame:000160 - time:26.07 22:10:40.23 - length:8 ---------- Dump:000 02 e1 8e 8e .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 71 N(R) 71 P 0 Dump:004 08 01 a2 4d ...M Q931: pd=Q.931/I.451, cr=0x22 (from destination), message=RELEASE: -- TE->NT - unit:0 - frame:000161 - time:26.07 22:10:40.23 - length:8 ---------- Dump:000 00 e1 8e 90 .... Q921: SAP=0 (Call Control), C, TEI=112, I-Frame: N(S) 71 N(R) 72 P 0 Dump:004 08 01 22 5a .."Z Q931: pd=Q.931/I.451, cr=0x22 (from origination), message=RELEASE COMPLETE: -- NT->TE - unit:0 - frame:000162 - time:26.07 22:10:40.25 - length:4 ---------- Dump:000 00 e1 01 90 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 72 PF 0 -- NT->TE - unit:0 - frame:000163 - time:26.07 22:10:44.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000164 - time:26.07 22:10:50.17 - length:4 ---------- Dump:000 02 e1 01 91 .... Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 72 PF 1 -- TE->NT - unit:0 - frame:000165 - time:26.07 22:10:50.17 - length:4 ---------- Dump:000 02 e1 01 91 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 72 PF 1 -- NT->TE - unit:0 - frame:000166 - time:26.07 22:10:54.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000167 - time:26.07 22:11:00.17 - length:4 ---------- Dump:000 02 e1 01 91 .... Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 72 PF 1 -- TE->NT - unit:0 - frame:000168 - time:26.07 22:11:00.17 - length:4 ---------- Dump:000 02 e1 01 91 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 72 PF 1 -- NT->TE - unit:0 - frame:000169 - time:26.07 22:11:04.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000170 - time:26.07 22:11:10.17 - length:4 ---------- Dump:000 02 e1 01 91 .... Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 72 PF 1 -- TE->NT - unit:0 - frame:000171 - time:26.07 22:11:10.17 - length:4 ---------- Dump:000 02 e1 01 91 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 72 PF 1 -- NT->TE - unit:0 - frame:000172 - time:26.07 22:11:14.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 -- NT->TE - unit:0 - frame:000173 - time:26.07 22:11:20.17 - length:4 ---------- Dump:000 02 e1 01 91 .... Q921: SAP=0 (Call Control), C, TEI=112, S-Frame: RR N(R) 72 PF 1 -- TE->NT - unit:0 - frame:000174 - time:26.07 22:11:20.17 - length:4 ---------- Dump:000 02 e1 01 91 .... Q921: SAP=0 (Call Control), R, TEI=112, S-Frame: RR N(R) 72 PF 1 -- NT->TE - unit:0 - frame:000175 - time:26.07 22:11:24.17 - length:4 ---------- Dump:000 02 df 01 47 ...G Q921: SAP=0 (Call Control), C, TEI=111, S-Frame: RR N(R) 35 PF 1 --------------2D53FFBE0E541E763E7E2DB9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 31 00:09:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA13935 for freebsd-isdn-outgoing; Fri, 31 Jul 1998 00:09:46 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA13927 for ; Fri, 31 Jul 1998 00:09:44 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (2206 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Fri, 31 Jul 1998 09:09:26 +0200 (METDST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-26) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m0z29Ly-0000f6C; Fri, 31 Jul 98 09:11 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: Tracing Kernel code (isppp) & possible isdnd bug In-Reply-To: <35C0AC09.68829FB5@hdz-ima.rwth-aachen.de> from Gerald Heinig at "Jul 30, 98 07:23:21 pm" To: heinig@hdz-ima.rwth-aachen.de (Gerald Heinig) Date: Fri, 31 Jul 1998 09:11:50 +0200 (METDST) Cc: freebsd-isdn@FreeBSD.ORG (ISDN Mailinglist) Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From the keyboard of Gerald Heinig: > Hellmuth Michaelis wrote: > > > >From the keyboard of Gerald Heinig: > > > > > Basically, i4b dials, *seems* to get an active connection and then releases the > > > line about 2 or 3 seconds afterwards. It then re-dials and says it has an active > > > connection, only to release it again after 2-3 seconds and so on, up until 10 > > > tries, when it stops. I've emphasised the "seems" because I'm not actually sure > > > whether the connection could really be established. > > > > I'd like to see an isdntrace output of this. > > Comin' up.... > > I'll make a proper effort from now on to get good traces. The one I've attached is > one I did more or less out of idle curiosity, but as far as I can remember, the > problem came up in this trace. At the ISDN level i don't see any problem. The local machine builds up a connection to the remote successfully. After some time, the _local_ machine disconnects in a normal way from the remote site. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 31 00:28:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA16179 for freebsd-isdn-outgoing; Fri, 31 Jul 1998 00:28:22 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA16169 for ; Fri, 31 Jul 1998 00:28:18 -0700 (PDT) (envelope-from hm@hcs.de) Received: from hcswork.hcs.de([192.76.124.5]) (2240 bytes) by hcshh.hcs.de via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Fri, 31 Jul 1998 09:28:00 +0200 (METDST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-26) Received: by hcswork.hcs.de (Smail3.1.29.0 #12) id m0z29dw-0000f6C; Fri, 31 Jul 98 09:30 METDST Message-Id: From: hm@hcs.de (Hellmuth Michaelis) Subject: Re: unexplainable CRC errors In-Reply-To: <3.0.5.32.19980730162235.00914a20@mail.scancall.no> from Marius Bendiksen at "Jul 30, 98 04:22:35 pm" To: Marius.Bendiksen@scancall.no (Marius Bendiksen) Date: Fri, 31 Jul 1998 09:30:23 +0200 (METDST) Cc: freebsd-isdn@FreeBSD.ORG Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From the keyboard of Marius Bendiksen: > I recieve crc errors on my FreeBSD box a short while > after having hung up a call using my normal phone. A > call which has been done by the FBSD system does not > produce such an error. The apparatus, cables and the > terminal seem unlikely candidates for this problem. > Has anyone else experienced this problem? I assume you are seeing ISAC (D-channel) CRC errors. The cause for ISAC CRC errors are almost always one of 1. - contact problems (some RJ45 plugs disconnect after being pulled 10 times) 2. - no, wrong, or improper termination 3. - wrong cable (one signal line exchanged with another, seen with brand new cables) 4. - defect NT adaptor 5. - defect ISDN card Item one is the most appropriate in almost all cases, i can easily reproduce it here if i pull the cable slightly out of one of my cards without disconnecting it fully. Under normal conditions one should _never_ see D-channel CRC errors and in the meantime i'm quite shure (correct me in case i'm wrong!) i4b is not the cause. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 31 00:50:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA18495 for freebsd-isdn-outgoing; Fri, 31 Jul 1998 00:50:50 -0700 (PDT) (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 AAA18490 for ; Fri, 31 Jul 1998 00:50:47 -0700 (PDT) (envelope-from martin@rumolt.teuto.de) Received: from rumolt.teuto.de (root@rumolt.teuto.de [194.77.23.161]) by linteuto.teuto.de (8.8.7/8.8.7) with ESMTP id JAA03926; Fri, 31 Jul 1998 09:50:41 +0200 Received: (from martin@localhost) by rumolt.teuto.de (8.8.8/8.8.7) id JAA05959; Fri, 31 Jul 1998 09:27:41 +0200 (MEST) From: Martin Husemann Message-Id: <199807310727.JAA05959@rumolt.teuto.de> Subject: Re: Tracing Kernel code (isppp) & possible isdnd bug To: heinig@hdz-ima.rwth-aachen.de (Gerald Heinig) Date: Fri, 31 Jul 1998 09:27:41 +0200 (MEST) Cc: hm@hcs.de, freebsd-isdn@FreeBSD.ORG In-Reply-To: <35C07C7E.E57ECB9C@hdz-ima.rwth-aachen.de> from "Gerald Heinig" at Jul 30, 98 04:00:30 pm 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 > Now, I'd like to investigate this problem, because it's definitely a bug: (if > the line is unavailable, then isdnd's claim about an active connection is false; > if the connection really is active, then i4b shouldn't release it without manual > intervention). I bet what you see is realy an active ISDN connection, but the PPP connection can not be established. The ppp code will then force isdnd to disconnect the call. Have you tried setting the isppp interface to DEBUG and watch the ppp state changes? Has LCP come up? Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 31 02:30:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA27802 for freebsd-isdn-outgoing; Fri, 31 Jul 1998 02:30:38 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA27796 for ; Fri, 31 Jul 1998 02:30:36 -0700 (PDT) (envelope-from simons@peti.gmd.de) Received: from peti.gmd.de (129.26.124.13) by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <13.10241AB0@listserv.gmd.de>; Fri, 31 Jul 1998 11:30:20 +0200 Received: by peti.gmd.de id LAA09556; Fri, 31 Jul 1998 11:30:20 +0200 (CEST) Date: Fri, 31 Jul 1998 11:30:20 +0200 (CEST) Message-Id: <199807310930.LAA09556@peti.gmd.de> From: Peter Simons To: freebsd-isdn@FreeBSD.ORG Subject: i4b 00.63-alpha-100798 and NetBSD/i386 1.3 Mime-Version: 1.0 (generated by tm-edit 7.92) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hi, I have recently installed the latest i4b snapshot on a regular i486 running NetBSD 1.3. Unfortunately I have experienced various problems. First of all, compilation of the kernel failed with the patches applied, because the code accesses a non-existing field in the "ifnet" structure. As best as I could I fixed this problem and installed everything, but as it seems the isdn-daemon isn't working. When I start it, the isdnd complains that my isdn card would be unknown (a fritz! card which is recognized during boot-time just fine) and exists without further notice. Does anyone know how to fix these problems? -peter -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 iQCVAwUBNcGOqg9HL1s0103BAQEywQP/a/ROeG57oAvxYkKnV7mG9hiDN8Apqz6l ihnAzAri/bMUOhsL8/am4JzvNlKQka9RIDHWmAvFgtzARdrVGV9ZJFsV5pUgT97s cWQEzon4/L+sSdhCFoxGD1HbuinLcdymGaV9UyvnXmhiVkcBNKuFhuqiAWw3xbq2 kcQBBTo80GY= =5jmt -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 31 02:40:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA29510 for freebsd-isdn-outgoing; Fri, 31 Jul 1998 02:40:16 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from mailhost.ah.nl (ahns.mis.ah.nl [141.93.32.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA29505 for ; Fri, 31 Jul 1998 02:40:12 -0700 (PDT) (envelope-from leo@x1c19e02.wau.mis.ah.nl) Received: from leobsd.wau.mis.ah.nl(x1c19e02.wau.mis.ah.nl[141.93.34.7]) (2319 bytes) by mailhost.ah.nl via sendmail with P:esmtp/R:inet_bind/T:smtp (sender: ) id for ; Fri, 31 Jul 1998 11:43:35 +0200 (MZT) (Smail-3.2.0.99 1997-Dec-4 #5 built 1998-Jul-18) Received: (from leo@localhost) by leobsd.wau.mis.ah.nl (8.8.8/8.6.12) id LAA09983; Fri, 31 Jul 1998 11:40:07 +0200 (CEST) Message-ID: <19980731114007.23645@wau.mis.ah.nl> Date: Fri, 31 Jul 1998 11:40:07 +0200 From: Leo Weppelman To: hm@hcs.de Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: Can't get dialback to work References: <19980720162306.38929@wau.mis.ah.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: from "Hellmuth Michaelis" on 1998/07/21 10:56 +0200 Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, it works now! The key was: - dialretries >= 2 - calledbackwait long enough to give the otherside a chance to dial in. I have it set to 30 currently. Attached the diffs I have for i4b.63 on NetBSD-current. I am not 100% sure of the tests on 'NetBSD1_3' in sppp.c. Leo. diff -ru i4b.org/driver/i4b_ipr.c i4b/driver/i4b_ipr.c --- i4b.org/driver/i4b_ipr.c Fri Jun 19 10:24:29 1998 +++ i4b/driver/i4b_ipr.c Wed Jul 15 23:17:31 1998 @@ -490,7 +490,12 @@ { /* disconnect ISDN line */ +#if defined(__NetBSD__) + i4b_l4_drvrdisc(BDRV_IPR, sc->sc_unit); +#endif +#if defined(__FreeBSD__) i4b_l4_drvrdisc(BDRV_IPR, ifp->if_unit); +#endif /* sc->sc_if.if_flags &= ~IFF_RUNNING; */ } diff -ru i4b.org/layer1/i4b_l1.h i4b/layer1/i4b_l1.h --- i4b.org/layer1/i4b_l1.h Tue Jun 23 16:03:32 1998 +++ i4b/layer1/i4b_l1.h Fri Jul 31 10:18:53 1998 @@ -375,6 +375,7 @@ #else /* not FreeBSD */ +extern void isic_recover __P((struct isic_softc *sc)); extern int isicattach __P((int flags, struct isic_softc *sc)); extern int isicintr __P((void *)); extern int isicprobe __P((struct isic_attach_args *ia)); diff -ru i4b.org/sppp/if_spppsubr.c i4b/sppp/if_spppsubr.c --- i4b.org/sppp/if_spppsubr.c Sun May 31 20:10:26 1998 +++ i4b/sppp/if_spppsubr.c Fri Jul 31 10:34:07 1998 @@ -28,6 +28,14 @@ #endif #include + +#ifdef NetBSD1_3 +# if NetBSD1_3 > 6 +# include "opt_inet.h" +# include "opt_iso.h" +# endif +#endif + #include #include #include To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 31 02:53:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA01284 for freebsd-isdn-outgoing; Fri, 31 Jul 1998 02:53:00 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA01277 for ; Fri, 31 Jul 1998 02:52:54 -0700 (PDT) (envelope-from heinig@hdz-ima.rwth-aachen.de) Received: from HDZ-IMA.RWTH-Aachen.de (majestix.hdz-ima.RWTH-Aachen.DE) by mail.rwth-aachen.de (PMDF V5.1-10 #30440) with ESMTP id <01J01QRPW6P40003RY@mail.rwth-aachen.de> for freebsd-isdn@FreeBSD.ORG; Fri, 31 Jul 1998 11:02:09 +0200 Received: from MAJESTIX/MAIL by HDZ-IMA.RWTH-Aachen.de (Mercury 1.20); Fri, 31 Jul 1998 11:01:25 +0000 Received: from MAIL by MAJESTIX (Mercury 1.20); Fri, 31 Jul 1998 11:00:56 +0000 Received: from hdz-ima.rwth-aachen.de by HDZ-IMA.RWTH-Aachen.de (Mercury 1.20) with ESMTP; Fri, 31 Jul 1998 11:00:53 +0000 Date: Fri, 31 Jul 1998 11:00:12 +0200 From: Gerald Heinig Subject: Re: Tracing Kernel code (isppp) & possible isdnd bug To: Martin Husemann Cc: freebsd-isdn@FreeBSD.ORG Message-id: <35C1879C.28EDB456@hdz-ima.rwth-aachen.de> MIME-version: 1.0 X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199807310727.JAA05959@rumolt.teuto.de> Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Martin Husemann wrote: > > Now, I'd like to investigate this problem, because it's definitely a bug: (if > > the line is unavailable, then isdnd's claim about an active connection is false; > > if the connection really is active, then i4b shouldn't release it without manual > > intervention). > > I bet what you see is realy an active ISDN connection, but the PPP connection > can not be established. The ppp code will then force isdnd to disconnect the > call. I suspected a problem with isppp, rather than with isdnd or the very low-level stuff. As I wrote in my first mail, isdnd doesn't seem to be doing anything wrong, since a kill & restart of isdnd doesn't change anything. > > > Have you tried setting the isppp interface to DEBUG and watch the ppp state > changes? Has LCP come up? I didn't think of that. I'll switch it on, thanks. Of course, I haven't had any problems at all since last weekend....(sigh) Hello Mr. Murphy.... :-( cheers Gerald To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 31 05:37:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA18779 for freebsd-isdn-outgoing; Fri, 31 Jul 1998 05:37:28 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from alushta.NL.net (alushta.NL.net [193.78.240.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA18770 for ; Fri, 31 Jul 1998 05:37:25 -0700 (PDT) (envelope-from bert_driehuis@nl.compuware.com) Received: from uniface by alushta.NL.net with UUCP id <332-9308>; Fri, 31 Jul 1998 14:36:57 +0200 Received: from nl.compuware.com (bertd@c1111.nl.compuware.com [172.16.16.36]) by dewmoth.nl.compuware.com (8.6.9/961125) with ESMTP id OAA26205 for ; Fri, 31 Jul 1998 14:36:12 +0200 Message-ID: <35C1BA3B.19A3A3B8@nl.compuware.com> Date: Fri, 31 Jul 1998 14:36:11 +0200 From: Bert Driehuis Organization: Compuware Europe, Amsterdam X-Mailer: Mozilla 4.05 [en] (X11; I; BSD/OS 3.1 i386) MIME-Version: 1.0 To: freebsd-isdn@FreeBSD.ORG Subject: Preparations for BSD/OS port Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Folks, I'm working on porting ISDN4BSD to BSD/OS 3.0. The telephony part works, and at that moment I needed sleep so I don't know what the actual status is. My bits will need a major cleanup anyhow, so BSD/OS users should not hold their breath! Anyways, there are some questions I have for the developers of the FreeBSD and NetBSD ports. To reduce the number of #ifdeffed sections, I'd like to propose using some #defines, along the lines of the PDEVSTATIC and FLAGS macro's that are used to hide differences between the *BSD's. One that springs to mind is the type of the second argument to the ioctl driver routine: on NetBSD it's an int, on FreeBSD and BSD/OS it's a u_long. How 'bout doing this in i4b_ioctl.h: #if defined(__FreeBSD__) || defined(__bsdi__) #define I4B_IOCTL_CMD_T u_long #else #define I4B_IOCTL_CMD_T int #endif Another, along the lines of the FLAGS definition in layer1/i4b_isic.c, is to use a #define PARMS to pass the right info down to the probe and attach routines (I should check my current sources to see if I still need those extra arguments for BSD/OS, but for the sake of argument let's assume it is still needed). This #define of course is #undeffed at the end of the routine. The biggest gain might come from removing "all" platform dependancies from the card drivers, and moving the OS dependent probe/attach stuff into i4b_isic.c (or at least into isolated sections in the card specific file). For example, the tel_s0163_probe in i4b_tel_s0163.c is defined now in two and soon three radically different ifdeffed routines, with the guts of the probe duplicated two or three times. This would require some serious thinking. Anyway, I'm not going to even *think* about tackling that issue :-) What do you think? #ifdef or #define? And if we want to use definitions like I4B_IOCTL_CMD_T throughout ISDN4BSD, which include file do we stick it in? i4b_ioctl.h was a easy choice for the ioctl routine, but it might be handy to stick it into an include file that each routine is guaranteed to include. Cheers, -- Bert -- Bert Driehuis, MIS -- bert_driehuis@nl.compuware.com -- +31-20-3116119 The grand leap of the whale up the Fall of Niagara is esteemed, by all who have seen it, as one of the finest spectacles in nature. -- Benjamin Franklin. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Fri Jul 31 08:02:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA06215 for freebsd-isdn-outgoing; Fri, 31 Jul 1998 08:02:51 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from berkeley.pickering.org (syntonet.demon.co.uk [193.237.143.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA06177 for ; Fri, 31 Jul 1998 08:02:40 -0700 (PDT) (envelope-from rob@pickering.org) Message-Id: <6111.199807311501@berkeley.pickering.org> Subject: i4b panic when card configured but not present (i4b-00.63-alpha-100798 on OpenBSD 2.3) To: freebsd-isdn@FreeBSD.ORG Date: Fri, 31 Jul 1998 16:01:23 +0100 (BST) From: Rob Pickering X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Whilst trying to build an OpenBSD 2.3 system with i4b-00.63-alpha-100798 I've found a problem when cards are configured but not installed. I installed i4b on a spare machine and built a kernel config for my Teles 16.3 but didn't yet install the card (because it's currently in my main production server running OpenBSD 2.2 + bisdn with an uptime of 63 days and I can't afford to move the system over until I'm confident it will probably work). When booting the machine without the card present the new kernel panics. I've tracked this down to isa_isic_probe() where the logic flow when a card isn't discovered allows args_unmap to be called twice on the same mapping. The second time causes OpenBSD to panic because the mapping doesn't now exist. The following small patch kludges the problem by making args_unmap mark as zero size mappings it has already removed so it doesn't try to remove them again. I guess a better fix would be to change the logic in isa_isic_probe so that unmap gets called exactly once for each mapping. *** isa_isic.c Fri Jun 19 10:26:22 1998 --- ../../layer1/isa_isic.c Fri Jul 31 15:25:36 1998 *************** *** 737,742 **** int i; for (i = 0; i < num_mappings; i++) ! if (maps[i].size) bus_space_unmap(maps[i].t, maps[i].h, maps[i].size); } --- 737,744 ---- int i; for (i = 0; i < num_mappings; i++) ! if (maps[i].size){ bus_space_unmap(maps[i].t, maps[i].h, maps[i].size); + maps[i].size = 0; + } } --- -- Rob Pickering. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Aug 1 00:18:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA12732 for freebsd-isdn-outgoing; Sat, 1 Aug 1998 00:18:42 -0700 (PDT) (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 AAA12727 for ; Sat, 1 Aug 1998 00:18:39 -0700 (PDT) (envelope-from martin@rumolt.teuto.de) Received: from rumolt.teuto.de (root@rumolt.teuto.de [194.77.23.161]) by linteuto.teuto.de (8.8.7/8.8.7) with ESMTP id JAA27244; Sat, 1 Aug 1998 09:18:30 +0200 Received: (from martin@localhost) by rumolt.teuto.de (8.8.8/8.8.7) id IAA04870; Sat, 1 Aug 1998 08:59:19 +0200 (MEST) From: Martin Husemann Message-Id: <199808010659.IAA04870@rumolt.teuto.de> Subject: Re: Preparations for BSD/OS port To: bert_driehuis@nl.compuware.com (Bert Driehuis) Date: Sat, 1 Aug 1998 08:59:18 +0200 (MEST) Cc: freebsd-isdn@FreeBSD.ORG In-Reply-To: <35C1BA3B.19A3A3B8@nl.compuware.com> from "Bert Driehuis" at Jul 31, 98 02:36:11 pm 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 > One that springs to mind is the type of > the second argument to the ioctl driver routine: on NetBSD it's an int, on > FreeBSD and BSD/OS it's a u_long. This is a good example. This code has always been wrong on NetBSD, but noone noticed (and it worked). Then someone changed the type for newer FreeBSD versions and let NetBSD use the old code. In fact it has been u_long for quite some time in NetBSD. > Another, along the lines of the FLAGS definition in layer1/i4b_isic.c, is to > use a #define PARMS to pass the right info down to the probe and attach > routines (I should check my current sources to see if I still need those extra > arguments for BSD/OS, but for the sake of argument let's assume it is still > needed). This might be usefull, but remember: attach and probe semantics are completely different and I don't see them coming closer together any time soon. So to clean up this mess it might be usefull to separate them completely. > For example, > the tel_s0163_probe in i4b_tel_s0163.c is defined now in two and soon three > radically different ifdeffed routines, with the guts of the probe duplicated > two or three times. Sometime ago we had a common include file for all the 16.3 based cards which used some generic macros to create the individual driver functions. Don't know why it was removed... I think a real worth amount of cleanup would happen if we would unify the parameters passed to the card specific drivers. The FreeBSD port should simply adopt the much more general sheme used for NetBSD now. We could try to make some compatibility no-op "bus_space" macros and may be done with all the #ifdef's in that part - besides probe and attach, due to the semantic differences there. Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Aug 1 00:32:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA13845 for freebsd-isdn-outgoing; Sat, 1 Aug 1998 00:32:11 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from mail.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA13840 for ; Sat, 1 Aug 1998 00:32:08 -0700 (PDT) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from casparc.ppp.net (casparc2.ppp.net [194.64.12.42]) by mail.ppp.net (8.8.8/8.8.8) with SMTP id JAA27692; Sat, 1 Aug 1998 09:32:02 +0200 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0z2W93-002ZjZC; Sat, 1 Aug 98 09:32 MET DST Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Sat, 1 Aug 1998 09:02:59 +0200 (CEST) (Smail-3.2.0.91 1997-Jan-14 #3 built 1998-Feb-14) Received: by bert.kts.org via sendmail with stdio id for freebsd-isdn@FreeBSD.ORG; Sat, 1 Aug 1998 08:56:57 +0200 (CEST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1998-Jun-6) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: Preparations for BSD/OS port In-Reply-To: <35C1BA3B.19A3A3B8@nl.compuware.com> from Bert Driehuis at "Jul 31, 98 02:36:11 pm" To: bert_driehuis@nl.compuware.com (Bert Driehuis) Date: Sat, 1 Aug 1998 08:56:57 +0200 (CEST) Cc: freebsd-isdn@FreeBSD.ORG Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bert Driehuis wrote: > I'm working on porting ISDN4BSD to BSD/OS 3.0. The telephony part works, Great! > FreeBSD and BSD/OS it's a u_long. How 'bout doing this in i4b_ioctl.h: > > #if defined(__FreeBSD__) || defined(__bsdi__) > #define I4B_IOCTL_CMD_T u_long > #else > #define I4B_IOCTL_CMD_T int > #endif Looks ok. > Another, along the lines of the FLAGS definition in layer1/i4b_isic.c, is to > use a #define PARMS to pass the right info down to the probe and attach Hmm, i dont like this. IMHO the differences in data types (as above) should be hidden, but function arguments not - its confusing. > The biggest gain might come from removing "all" platform dependancies from the > card drivers, and moving the OS dependent probe/attach stuff into i4b_isic.c > (or at least into isolated sections in the card specific file). For example, > the tel_s0163_probe in i4b_tel_s0163.c is defined now in two and soon three > radically different ifdeffed routines, with the guts of the probe duplicated > two or three times. This would require some serious thinking. Anyway, I'm not > going to even *think* about tackling that issue :-) Perhaps this can go in three files, i4b_probeattach_fbsd.c, i4b_probeattach_nbsd.c and i4b_probeattach_bsdos.c ? > What do you think? #ifdef or #define? And if we want to use definitions like > I4B_IOCTL_CMD_T throughout ISDN4BSD, which include file do we stick it in? i4b_global.h hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe A duck is like a bicycle because they both have two wheels except the duck (terry@cs.weber.edu) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Aug 1 01:31:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA18814 for freebsd-isdn-outgoing; Sat, 1 Aug 1998 01:31:40 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from news.IAEhv.nl (news.IAEhv.nl [194.151.64.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA18808 for ; Sat, 1 Aug 1998 01:31:38 -0700 (PDT) (envelope-from marc@bowtie.nl) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.8.8/1.63) with IAEhv.nl; pid 20160 on Sat, 1 Aug 1998 08:31:21 GMT; id IAA20160 efrom: marc@bowtie.nl; eto: UNKNOWN Received: from localhost (localhost [127.0.0.1]) by bowtie.nl (8.8.8/8.8.8) with ESMTP id KAA17791; Sat, 1 Aug 1998 10:25:17 +0200 (CEST) (envelope-from marc@bowtie.nl) Message-Id: <199808010825.KAA17791@bowtie.nl> To: hm@hcs.de Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: Tracing Kernel code (isppp) & possible isdnd bug In-reply-to: hm's message of Fri, 31 Jul 1998 09:11:50 +0200. Reply-to: marc@bowtie.nl Date: Sat, 01 Aug 1998 10:25:17 +0200 From: Marc van Kempen Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Hellmuth Michaelis writes: >From the keyboard of Gerald Heinig: > >> Hellmuth Michaelis wrote: >> >> > >From the keyboard of Gerald Heinig: >> > >> > > Basically, i4b dials, *seems* to get an active connection and then releases the >> > > line about 2 or 3 seconds afterwards. It then re-dials and says it has an active >> > > connection, only to release it again after 2-3 seconds and so on, up until 10 >> > > tries, when it stops. I've emphasised the "seems" because I'm not actually sure >> > > whether the connection could really be established. >> > >> > I'd like to see an isdntrace output of this. >> >> Comin' up.... >> >> I'll make a proper effort from now on to get good traces. The one I've attached is >> one I did more or less out of idle curiosity, but as far as I can remember, the >> problem came up in this trace. > >At the ISDN level i don't see any problem. The local machine builds up a >connection to the remote successfully. After some time, the _local_ machine >disconnects in a normal way from the remote site. > 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:04 schopenhauer /kernel: isppp0: lcp open(initial) Aug 1 10:01:04 schopenhauer /kernel: isppp0: phase establish Aug 1 10:01:04 schopenhauer /kernel: isppp0: Up event Aug 1 10:01:04 schopenhauer /kernel: isppp0: lcp up(starting) Aug 1 10:01:04 schopenhauer /kernel: isppp0: lcp output Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp input(req-sent): Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp parse opts: magic auth-proto Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp parse opt values: magic 0xb94cd32c auth-proto send conf-ack Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp output Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp input(ack-sent): Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp tlu Aug 1 10:01:05 schopenhauer /kernel: isppp0: phase authenticate Aug 1 10:01:05 schopenhauer /kernel: isppp0: pap output Aug 1 10:01:05 schopenhauer /kernel: isppp0: pap success: 3U 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 Aug 1 10:01:05 schopenhauer /kernel: isppp0: lcp input(closing): 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) etc... This just happened while I had been making several connections already (regular timeouts from the dial-up stuff). From one moment to the other it stopped working. A reboot seems to solve it every time, a restart of the isdn daemon, or ifconfig'ing the isppp0 interface up/down doesn't seem to affect the problem. I'll send an isdntrace too, next time it happens. Here is some more output from my messages file, I think this is the output from 'isdndebug -l 4 -m'. Aug 1 09:51:14 schopenhauer /kernel: isppp0: phase establish Aug 1 09:51:14 schopenhauer /kernel: i4b-L4-reserve_cd: found free cd - index=0 cdid=79 Aug 1 09:51:14 schopenhauer /kernel: i4b-L4-cd_by_cdid: found cdid - index=0 cdid=79 cr=23 Aug 1 09:51:14 schopenhauer /kernel: i4b-L4-i4bioctl: I4B_CONNECT_REQ times, unitlen=150 idle=30 earlyhup=5 Aug 1 09:51:14 schopenhauer /kernel: i4b-L4-cd_by_cdid: found cdid - index=0 cdid=79 cr=12 Aug 1 09:51:15 schopenhauer /kernel: i4b-L4-cd_by_unitcr: found cd, index=0 cdid=79 cr=12 Aug 1 09:51:15 schopenhauer /kernel: i4b-L4-cd_by_unitcr: found cd, index=0 cdid=79 cr=12 Aug 1 09:51:15 schopenhauer /kernel: i4b-L4-i4b_l4_connect_active_ind: last_active/connect_time=901957875 Aug 1 09:51:15 schopenhauer /kernel: i4b-L4-i4b_l4_setup_timeout: 901957875: outgoing-call, start 115 sec nocheck window Aug 1 09:51:16 schopenhauer /kernel: isppp0: phase authenticate Aug 1 09:51:16 schopenhauer /kernel: isppp0: phase network Aug 1 09:51:16 schopenhauer /kernel: isppp0: phase terminate Aug 1 09:51:16 schopenhauer /kernel: isppp0: phase dead Aug 1 09:51:16 schopenhauer /kernel: i4b-L4-cd_by_cdid: found cdid - index=0 cdid=79 cr=12 Aug 1 09:51:16 schopenhauer /kernel: i4b-L4-cd_by_unitcr: found cd, index=0 cdid=79 cr=12 Aug 1 09:51:16 schopenhauer /kernel: i4b-L4-freecd_by_cd: releasing cd - index=0 cdid=79 cr=12 I'll attach the output from 'isdndebug -m' from another occasion, I didn't enable that output this time. (I couldn't exactly determine where to start listing the debug output, so I may have included a bit more context than neccessary, sorry if it's too long). Jul 30 09:39:39 schopenhauer /kernel: i4b-L2-i4b_T200_stop: unit 0 Jul 30 09:39:39 schopenhauer /kernel: i4b-L2-i4b_next_l2state: FSM S-event [EV_RXRR]: [ST_MULTIFR => ST_MULTIFR] Jul 30 09:39:39 schopenhauer /kernel: isppp0: phase authenticate Jul 30 09:39:39 schopenhauer /kernel: isppp0: phase network Jul 30 09:39:39 schopenhauer /kernel: isppp0: phase terminate Jul 30 09:39:39 schopenhauer /kernel: isppp0: phase dead Jul 30 09:39:39 schopenhauer /kernel: i4b-L4-cd_by_cdid: found cdid - index=0 cdid=124 cr=41 Jul 30 09:39:39 schopenhauer /kernel: i4b-L3-next_l3state: L3 FSM event [EV_DISCRQ - L4 DISC REQ]: [ST_U10 - Active => ST_U11 - $ Jul 30 09:39:39 schopenhauer /kernel: i4b-L3-F_DCRQ: FSM function F_DCRQ executing Jul 30 09:39:39 schopenhauer /kernel: i4b-L3-i4b_l3_tx_disconnect: tx DISCONNECT for cr 41 Jul 30 09:39:39 schopenhauer /kernel: i4b-L2-i4b_dl_data_req: unit 0 Jul 30 09:39:39 schopenhauer /kernel: i4b-L1-ph_data_req: ISAC_TX_ACTIVE set Jul 30 09:39:39 schopenhauer /kernel: i4b-L2-i4b_T200_start: unit 0 Jul 30 09:39:40 schopenhauer /kernel: i4b-L3-T305_start: cr = 41 Jul 30 09:39:40 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x10 Jul 30 09:39:40 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x80 Jul 30 09:39:40 schopenhauer /kernel: i4b-L2-i4b_rxd_s_frame: rx'd RR, N(R) = 27 Jul 30 09:39:40 schopenhauer /kernel: i4b-L2-F_MF17: FSM function F_MF17 executing Jul 30 09:39:40 schopenhauer /kernel: i4b-L2-i4b_T200_stop: unit 0 Jul 30 09:39:40 schopenhauer /kernel: i4b-L2-i4b_next_l2state: FSM S-event [EV_RXRR]: [ST_MULTIFR => ST_MULTIFR] Jul 30 09:39:40 schopenhauer /kernel: i4b-L1-isic_hscx_irq: received invalid Frame Jul 30 09:39:40 schopenhauer /kernel: i4b-L1-isic_hscx_irq: CRC check failed Jul 30 09:39:40 schopenhauer /kernel: i4b-L1-isic_hscx_irq: Receive message aborted Jul 30 09:39:40 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x80 Jul 30 09:39:40 schopenhauer /kernel: i4b-L3-i4b_decode_q931: Call Ref, len 1, val 41, flag 1 Jul 30 09:39:40 schopenhauer /kernel: i4b-L4-cd_by_unitcr: found cd, index=0 cdid=124 cr=41 Jul 30 09:39:40 schopenhauer /kernel: i4b-L3-i4b_decode_q931_message: RELEASE message Jul 30 09:39:40 schopenhauer /kernel: i4b-L3-i4b_decode_q931_codeset0: IEI_CAUSE = 16 Jul 30 09:39:40 schopenhauer /kernel: i4b-L3-next_l3state: L3 FSM event [EV_RELEASE - rxd REL]: [ST_U11 - Disc Req => ST_U0 - Nu$ Jul 30 09:39:40 schopenhauer /kernel: i4b-L3-F_11J: FSM function F_11J executing Jul 30 09:39:40 schopenhauer /kernel: i4b-L3-T305_stop: cr = 41 Jul 30 09:39:40 schopenhauer /kernel: i4b-L3-i4b_l3_tx_release_complete: tx RELEASE COMPL for cr 41 Jul 30 09:39:40 schopenhauer /kernel: i4b-L2-i4b_dl_data_req: unit 0 Jul 30 09:39:40 schopenhauer /kernel: i4b-L1-ph_data_req: ISAC_TX_ACTIVE set Jul 30 09:39:40 schopenhauer /kernel: i4b-L2-i4b_T200_start: unit 0 Jul 30 09:39:40 schopenhauer /kernel: i4b-L1-isic_bchannel_setup: unit=0, channel=0, deactivate Jul 30 09:39:40 schopenhauer /kernel: i4b-L4-freecd_by_cd: releasing cd - index=0 cdid=124 cr=41 Jul 30 09:39:40 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x10 Jul 30 09:39:40 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x80 Jul 30 09:39:40 schopenhauer /kernel: i4b-L2-i4b_rxd_s_frame: rx'd RR, N(R) = 28 Jul 30 09:39:40 schopenhauer /kernel: i4b-L2-F_MF17: FSM function F_MF17 executing Jul 30 09:39:40 schopenhauer /kernel: i4b-L2-i4b_T200_stop: unit 0 Jul 30 09:39:40 schopenhauer /kernel: i4b-L2-i4b_next_l2state: FSM S-event [EV_RXRR]: [ST_MULTIFR => ST_MULTIFR] Jul 30 09:39:49 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x80 Jul 30 09:39:49 schopenhauer /kernel: i4b-L2-i4b_rxd_u_frame: DISC, sapi = 0, tei = 65 Jul 30 09:39:49 schopenhauer /kernel: i4b-L2-i4b_next_l2state: FSM event [EV_RXDISC]: [ST_MULTIFR/6 => ST_TEI_ASGD/3] Jul 30 09:39:49 schopenhauer /kernel: i4b-L2-F_MF08: FSM function F_MF08 executing Jul 30 09:39:49 schopenhauer /kernel: i4b-L2-i4b_tx_ua: tx UA, tei = 65 Jul 30 09:39:49 schopenhauer /kernel: i4b-L1-ph_data_req: ISAC_TX_ACTIVE set Jul 30 09:39:49 schopenhauer /kernel: i4b-L2-i4b_T200_stop: unit 0 Jul 30 09:39:49 schopenhauer /kernel: i4b-L2-i4b_next_l2state: FSM executing postfsmfunc! Jul 30 09:39:49 schopenhauer /kernel: i4b-L3-i4b_dl_release_ind: unit=0 DL released! Jul 30 09:39:49 schopenhauer /kernel: i4b-L3-i4b_dl_release_ind: no cdid for unit 0 found Jul 30 09:39:49 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x10 Jul 30 09:39:58 schopenhauer /kernel: isppp0: phase establish Jul 30 09:39:58 schopenhauer /kernel: i4b-L4-reserve_cd: found free cd - index=0 cdid=125 Jul 30 09:39:58 schopenhauer /kernel: i4b-L4-cd_by_cdid: found cdid - index=0 cdid=125 cr=41 Jul 30 09:39:58 schopenhauer /kernel: i4b-L4-i4bioctl: I4B_CONNECT_REQ times, unitlen=90 idle=30 earlyhup=5 Jul 30 09:39:58 schopenhauer /kernel: i4b-L4-cd_by_cdid: found cdid - index=0 cdid=125 cr=114 Jul 30 09:39:58 schopenhauer /kernel: i4b-L3-next_l3state: L3 FSM event [EV_SETUPRQ - L4 SETUP REQ]: [ST_U0 - Null => ST_SUSE - $ Jul 30 09:39:58 schopenhauer /kernel: i4b-L3-F_00A: FSM function F_00A executing Jul 30 09:39:58 schopenhauer /kernel: i4b-L2-i4b_dl_establish_req: unit 0 Jul 30 09:39:58 schopenhauer /kernel: i4b-L2-i4b_next_l2state: FSM event [EV_DLESTRQ]: [ST_TEI_ASGD/3 => ST_AW_EST/4] Jul 30 09:39:58 schopenhauer /kernel: i4b-L2-F_T01: FSM function F_T01 executing Jul 30 09:39:58 schopenhauer /kernel: i4b-L2-i4b_tx_sabme: tx SABME, tei = 65 Jul 30 09:39:58 schopenhauer /kernel: i4b-L1-ph_data_req: ISAC_TX_ACTIVE set Jul 30 09:39:58 schopenhauer /kernel: i4b-L2-i4b_T200_restart: unit 0 Jul 30 09:39:58 schopenhauer /kernel: i4b-L3-T303_start: cr = 114 Jul 30 09:39:58 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x10 Jul 30 09:39:58 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x80 Jul 30 09:39:58 schopenhauer /kernel: i4b-L2-i4b_rxd_u_frame: UA, sapi = 0, tei = 65 Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-F_AE09: FSM function F_AE09 executing Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_T200_stop: unit 0 Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_next_l2state: FSM S-event [EV_RXUA]: [ST_AW_EST => ST_MULTIFR] Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_next_l2state: FSM executing postfsmfunc! Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-i4b_dl_establish_cnf: unit=0, index=0 cdid=125 cr=114 Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-next_l3state: L3 FSM event [EV_DLESTCF - L2 DL_Est_Cnf]: [ST_OW - Out Wait EST => S$ Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-F_DECF1: FSM function F_DECF1 executing Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-i4b_l3_tx_setup: tx SETUP for cr 114 Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_dl_data_req: unit 0 Jul 30 09:39:59 schopenhauer /kernel: i4b-L1-ph_data_req: ISAC_TX_ACTIVE set Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_T200_start: unit 0 Jul 30 09:39:59 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x10 Jul 30 09:39:59 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x10 Jul 30 09:39:59 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x80 Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_rxd_s_frame: rx'd RR, N(R) = 1 Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-F_MF17: FSM function F_MF17 executing Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_T200_stop: unit 0 Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_next_l2state: FSM S-event [EV_RXRR]: [ST_MULTIFR => ST_MULTIFR] Jul 30 09:39:59 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x80 Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-i4b_decode_q931: Call Ref, len 1, val 114, flag 1 Jul 30 09:39:59 schopenhauer /kernel: i4b-L4-cd_by_unitcr: found cd, index=0 cdid=125 cr=114 Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-i4b_decode_q931_message: CALL_PROCEEDING message Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-i4b_decode_q931_codeset0: IEI_CHANNELID - channel 0, exclusive = 1 Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-next_l3state: L3 FSM event [EV_CALLPRC - rxd CALL PROC]: [ST_U1 - Out Init => ST_U3$ Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-F_01M: FSM function F_01M executing Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-T303_stop: cr = 114 Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-T310_start: cr = 114 Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_tx_rr_response: tx RR, unit = 0 Jul 30 09:39:59 schopenhauer /kernel: i4b-L1-ph_data_req: ISAC_TX_ACTIVE set Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_T200_stop: unit 0 Jul 30 09:39:59 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x10 Jul 30 09:39:59 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x80 Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-i4b_decode_q931: Call Ref, len 1, val 114, flag 1 Jul 30 09:39:59 schopenhauer /kernel: i4b-L4-cd_by_unitcr: found cd, index=0 cdid=125 cr=114 Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-i4b_decode_q931_message: CONNECT message Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-i4b_decode_q931_codeset0: IEI_DATETIME Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-i4b_decode_q931_codeset0: IEI_CONCTDNO Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-next_l3state: L3 FSM event [EV_CONNECT - rxd CONNECT]: [ST_U3 - Out Proc => ST_U10 $ Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-F_03O: FSM function F_03O executing Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-T310_stop: cr = 114 Jul 30 09:39:59 schopenhauer /kernel: i4b-L3-i4b_l3_tx_connect_ack: tx CONNECT ACK for cr 114 Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_dl_data_req: unit 0 Jul 30 09:39:59 schopenhauer /kernel: i4b-L1-ph_data_req: ISAC_TX_ACTIVE set Jul 30 09:39:59 schopenhauer /kernel: i4b-L2-i4b_T200_start: unit 0 Jul 30 09:39:59 schopenhauer /kernel: i4b-L4-i4b_l4_connect_active_ind: last_active/connect_time=901784398 Jul 30 09:39:59 schopenhauer /kernel: i4b-L1-isic_bchannel_setup: unit=0, channel=0, activate Jul 30 09:40:00 schopenhauer /kernel: i4b-L4-i4b_l4_setup_timeout: 901784398: outgoing-call, start 55 sec nocheck window Jul 30 09:40:00 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x10 Jul 30 09:40:00 schopenhauer /kernel: i4b-L1-isic_isac_irq: ista =0x80 Jul 30 09:40:00 schopenhauer /kernel: i4b-L2-i4b_rxd_s_frame: rx'd RR, N(R) = 2 Jul 30 09:40:00 schopenhauer /kernel: i4b-L2-F_MF17: FSM function F_MF17 executing Jul 30 09:40:00 schopenhauer /kernel: i4b-L2-i4b_T200_stop: unit 0 Jul 30 09:40:00 schopenhauer /kernel: i4b-L2-i4b_next_l2state: FSM S-event [EV_RXRR]: [ST_MULTIFR => ST_MULTIFR] Jul 30 09:40:00 schopenhauer /kernel: isppp0: phase authenticate Jul 30 09:40:00 schopenhauer /kernel: isppp0: phase network Jul 30 09:40:00 schopenhauer /kernel: isppp0: phase terminate Jul 30 09:40:00 schopenhauer /kernel: isppp0: phase dead Regards, Marc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message From owner-freebsd-isdn Sat Aug 1 06:32:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA12746 for freebsd-isdn-outgoing; Sat, 1 Aug 1998 06:32:17 -0700 (PDT) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from mail.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA12741 for ; Sat, 1 Aug 1998 06:32:15 -0700 (PDT) (envelope-from ernie!bert.kts.org!hm@ppp.net) Received: from casparc.ppp.net (casparc2.ppp.net [194.64.12.42]) by mail.ppp.net (8.8.8/8.8.8) with SMTP id PAA00288; Sat, 1 Aug 1998 15:32:02 +0200 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0z2blR-002ZjcC; Sat, 1 Aug 98 15:32 MET DST Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Sat, 1 Aug 1998 15:04:33 +0200 (CEST) (Smail-3.2.0.91 1997-Jan-14 #3 built 1998-Feb-14) Received: by bert.kts.org via sendmail with stdio id for freebsd-isdn@FreeBSD.ORG; Sat, 1 Aug 1998 14:58:32 +0200 (CEST) (Smail-3.2.0.94 1997-Apr-22 #1 built 1998-Jun-6) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: Preparations for BSD/OS port In-Reply-To: <199808010659.IAA04870@rumolt.teuto.de> from Martin Husemann at "Aug 1, 98 08:59:18 am" To: martin@rumolt.teuto.de (Martin Husemann) Date: Sat, 1 Aug 1998 14:58:32 +0200 (CEST) Cc: bert_driehuis@nl.compuware.com, freebsd-isdn@FreeBSD.ORG Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Martin Husemann wrote: > Sometime ago we had a common include file for all the 16.3 based cards which > used some generic macros to create the individual driver functions. Don't know > why it was removed... I removed it because - IMHO - that made the code more unreadable and removed more obviousness from it and i didn't and don't like that. Functions are functions and i simply don't like them to be replaced by macros generating functions included from .h-files. For me, the top priority is readability, second maintainability, then comes functionality, portability and speed. > I think a real worth amount of cleanup would happen if we would unify the > parameters passed to the card specific drivers. The FreeBSD port should > simply adopt the much more general sheme used for NetBSD now. We could try > to make some compatibility no-op "bus_space" macros and may be done with > all the #ifdef's in that part - besides probe and attach, due to the > semantic differences there. As long as the things above apply this is fine for me. hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe A duck is like a bicycle because they both have two wheels except the duck (terry@cs.weber.edu) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message