From owner-freebsd-isdn@FreeBSD.ORG Thu Nov 29 16:25:49 2012 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15300543 for ; Thu, 29 Nov 2012 16:25:49 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 948BF8FC15 for ; Thu, 29 Nov 2012 16:25:48 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 8AFDD5CF33; Thu, 29 Nov 2012 17:25:47 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id thNgEZUeTkec; Thu, 29 Nov 2012 17:25:46 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 87FEC5CF39; Thu, 29 Nov 2012 17:25:46 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id 6871550876; Thu, 29 Nov 2012 17:25:46 +0100 (CET) Message-ID: <50B78C8A.2040701@incore.de> Date: Thu, 29 Nov 2012 17:25:46 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ISDN4BSD (HPS version) is going into ports References: <509E87EF.9070607@incore.de> <201211151812.32616.hselasky@c2i.net> <50AF5B79.5050802@incore.de> <201211241222.52897.hselasky@c2i.net> In-Reply-To: <201211241222.52897.hselasky@c2i.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 16:25:49 -0000 Hi, > I've made a new release of ISDN4BSD, now version 2.0.6. I4B SVN has been > updated with new ports. I tested all the last changes in version 2.0.6 of isdn4bsd-kmod and isdn4-utils and everything worked as expected. Thanks! >> One thing is left: the handling of DISCONNECT including error codes like >> "busy". We had some discussion about this in late 2010, I wrote >> >>> My understanding of the standard closing of a Q.931 connection is >>> >>> --> DISCONNECT >>> <-- RELEASE >>> --> RELEASE_COMPLETE >>> >>> it is like closing a tcp socket (-> FIN; <- FIN+ACK; -> ACK). I have >>> never seen an example that RELEASE and RELESE_COMPLETE is send in the >>> same direction. Your method of finishing a Q.931 connection is correct >>> but not standard: In the active case you send RELEASE_COMLETE, in the >>> passive case you answer the incoming DISCONNECT with RELEASE_COMPLETE. >> and your answer was that the statemachine in ISDN4BSD must be changed to >> accomplish my requirement. If you have a patch for this, I would like to >> test this. > > I haven't had time to look into this one yet. I will see if I can find some > time to do this. Else keep in reminding me or if you want you can suggest a > patch. I think we already have a DISCONNECT state, where we can go instead of > release complete. I'm just not sure how that will interact with STATUS > enquiry, what state we get back. > > Does the Q.931 define a maximum time before we can expect a RELEASE_COMPLETE? After sending out a DISCONNECT to the D-channel the timer T105 should be started (default ist 30 sec). This is the information given in Table 9-2 of Recommendation Q.931 (05/98) free available for download at www.itu.int/rec/T-REC-Q.931-199805-I/e. > isdnconfig -u XXX status_enquiry_enable > isdnconfig -u XXX status_enquiry_disable Works perfect. One more thing: I have some ISDN cards "AVM Fritz!Card version 2 PCI": ihfc1@pci0:0:7:0: class=0x028000 card=0x0e001244 chip=0x0e001244 rev=0x02 hdr=0x00 vendor = 'AVM Audiovisuelles MKTG & Computer GmbH' device = 'Fritz!PCI v2.0 ISDN Controller' class = network bar [10] = type Memory, range 32, base 0xfb145000, size 32, enabled bar [14] = type I/O Port, range 32, base 0x54c0, size 32, enabled cap 01[40] = powerspec 2 supports D0 D2 D3 current D0 and know that these cards do not work with isdn4bsd at the moment mainly because of missing information from AVM. At the moment these cards run in servers or soekris devices with FreeBSD 6 Stable without any problem for years now using the ifpi2 driver of FreeBSD 6 and the old isdnd: ifpi2-0@pci0:14:0: class=0x028000 card=0x0e001244 chip=0x0e001244 rev=0x02 hdr=0x00 vendor = 'AVM AUDIOVISUELLES MKTG & Computer GmbH' device = 'Fritz!PCI v2.0 ISDN Controller' class = network Because I would like to update all these boxes from FreeBSD 6 to FreeBSD >= 8, I will try to get isdnd working with isdn4bsd-kmod/utils. First step of analyze is done: I see in the isdntrace that several of the incoming D-channel frames have an extra byte at the end of the frame: 10101110 UNKNOWN single octet IE = 0xae Further I see many single outgoing bytes on L3 level: L3 04 AE 10101110 Protocol = Other Layer 3 or X.25 (0xae) On the other side of the ISDN-line all length are correct. Maybe there is a "one byte length problem" in the D-channel communication between the i4b driver and the card. -- Andreas Longwitz From owner-freebsd-isdn@FreeBSD.ORG Fri Nov 30 07:43:12 2012 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 940FCA8E for ; Fri, 30 Nov 2012 07:43:12 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 140978FC13 for ; Fri, 30 Nov 2012 07:43:10 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 352435807; Fri, 30 Nov 2012 08:43:02 +0100 From: Hans Petter Selasky To: Andreas Longwitz Subject: Re: ISDN4BSD (HPS version) is going into ports Date: Fri, 30 Nov 2012 08:44:37 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <509E87EF.9070607@incore.de> <201211241222.52897.hselasky@c2i.net> <50B78C8A.2040701@incore.de> In-Reply-To: <50B78C8A.2040701@incore.de> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@ =?iso-8859-1?q?d2+AyewRX=7DmAm=3BYp=0A=09=7CU=5B?=@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y> =?iso-8859-1?q?Y=7Dk1C4TfysrsUI=0A=09-=25GU9V5=5DiUZF=26nRn9mJ=27=3F=26?=>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201211300844.37917.hselasky@c2i.net> Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 07:43:12 -0000 On Thursday 29 November 2012 17:25:46 Andreas Longwitz wrote: > First step of analyze is done: I see in the isdntrace that several of > the incoming D-channel frames have an extra byte at the end of the frame: > 10101110 UNKNOWN single octet IE = 0xae > Further I see many single outgoing bytes on L3 level: > L3 04 AE 10101110 Protocol = Other Layer 3 or X.25 (0xae) > > On the other side of the ISDN-line all length are correct. Maybe there > is a "one byte length problem" in the D-channel communication between > the i4b driver and the card. Hi, Maybe you can read out the chip numbers? Maybe some of the chips used are documented. Should not be impossible to get this working! The driver is located here: src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h Should be easy to compare with the old driver from FreeBSD 6.x. --HPS From owner-freebsd-isdn@FreeBSD.ORG Sat Dec 1 23:07:46 2012 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9A25D3A for ; Sat, 1 Dec 2012 23:07:46 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 3206C8FC13 for ; Sat, 1 Dec 2012 23:07:45 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id BBB505CFCB; Sun, 2 Dec 2012 00:07:38 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id yIWM3um7-ZNM; Sun, 2 Dec 2012 00:07:37 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 920445CFC5; Sun, 2 Dec 2012 00:07:37 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 1C9315083F; Sun, 2 Dec 2012 00:07:37 +0100 (CET) Message-ID: <50BA8DB8.1090004@incore.de> Date: Sun, 02 Dec 2012 00:07:36 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ISDN4BSD (HPS version) is going into ports References: <509E87EF.9070607@incore.de> <201211241222.52897.hselasky@c2i.net> <50B78C8A.2040701@incore.de> <201211300844.37917.hselasky@c2i.net> In-Reply-To: <201211300844.37917.hselasky@c2i.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 23:07:46 -0000 Hi, >> First step of analyze is done: I see in the isdntrace that several of >> the incoming D-channel frames have an extra byte at the end of the frame: >> 10101110 UNKNOWN single octet IE = 0xae >> Further I see many single outgoing bytes on L3 level: >> L3 04 AE 10101110 Protocol = Other Layer 3 or X.25 (0xae) I have to correct myself: Further I see many single incoming (not outgoing) bytes. In the meantime I am convinced that every incoming L2 frame from the card has exactly one superfluos byte at the end. >> On the other side of the ISDN-line all length are correct. Maybe there >> is a "one byte length problem" in the D-channel communication between >> the i4b driver and the card. > > Maybe you can read out the chip numbers? Maybe some of the chips used are > documented. Should not be impossible to get this working! Would be fine! The driver working in FreeBSD 6 gives ifpi2-0: ISACSX PSB3186, but this is hardcoded in the source. On the chip I can read "AVM PSB 3100 F". > Should be easy to compare with the old driver from FreeBSD 6.x. In the meantime I was able to do a verbose boot. Sounds strange, but there was a another problem solved by Andriy Gapon: lists.freebsd.org/pipermail/freebsd-stable/2012-November/070634.html. During verbose boot i4b gives for my AVM Fritz!Card version 2 PCI card: i4b-L1 ihfc1: ihfc_pnp_probe_sub: this unit has 6 transmit and receive channels and 1 sub-controllers i4b-L1 ihfc1: ihfc_alloc_all_resources: Internal IRQ-address: 0x17 ihfc1: Reserved 0x20 bytes for rid 0x10 type 3 at 0xfb145000 i4b-L1 ihfc1: ihfc_fifo_setup_soft: HFC_MAX_FRAMES >= f->fm.h.Fsize i4b-L1 ihfc1: avm_pci_chip_status_read: status=0x48 i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x20 i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00 i4b-L1 ihfc1: __ihfc_chip_interrupt: del=00000014 ista=0x0000, exir=0x0000, h_ista=0x0000, h_exir=0x0000, s_int_s1=0x00 i4b-L1 ihfc1: ihfc_fsm_update: Undefined state: 1!. (p0,a0,c0,u0,d0,i1) ihfc1: port 0x54c0-0x54df mem 0xfb145000-0xfb14501f irq 23 at device 7.0 on pci0 i4b-L1 ihfc1: ihfc_post_setup: Setting up IRQ ihfc1: [MPSAFE] ihfc1: [ITHREAD] ihfc1: Attaching I4B controller 0. i4b-L1 ihfc1: ihfc_B_get_fifo_translator: ihfc1: Creating /dev/ihfc0.X. i4b-L1 ihfc1: avm_pci_chip_status_read: status=0x49 i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x11 i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90 i4b-L1 ihfc1: ihfc_fsm_update: Activate indication (priority=8/9). (p0,a1,c1,u0,d0,i0) i4b-L1 ihfc1: fsm_write: Start activation, cmd[0]=0x20 i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00 i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00 i4b-L1 ihfc1: __ihfc_chip_interrupt: del=00000010 ista=0x0000, exir=0x0000, h_ista=0x0000, h_exir=0x0000, s_int_s1=0x00 Maybe the "Undefined state" message in ihfc_fsm_update gives a hint ? P.S. With bootverbose in function ihfc_pnp_probe_sub() the debugbit L1_HFC_DBG is set producing very very lot of messages and the system comes to complete congestion, therefore after a few minutes my watchdog triggers, If you think this not ok, then I can give more details. At the moment I avoid this problem reliable with "isdndebug -d" as soon as userland gets control after verbose boot. -- Andreas Longwitz