From owner-freebsd-isdn@FreeBSD.ORG Tue Jan 15 11:28:16 2013 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A027180 for ; Tue, 15 Jan 2013 11:28:16 +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 656C8E6F for ; Tue, 15 Jan 2013 11:28:16 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id EA46C5D4C9; Tue, 15 Jan 2013 12:28:14 +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 MC4JiUVJRobk; Tue, 15 Jan 2013 12:28:14 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id DE2CB5D4C7; Tue, 15 Jan 2013 12:28:03 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id D29BF50880; Tue, 15 Jan 2013 12:28:03 +0100 (CET) Message-ID: <50F53D43.2070404@incore.de> Date: Tue, 15 Jan 2013 12:28:03 +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> <201301111150.47312.hselasky@c2i.net> <50F41F19.2050205@incore.de> <201301141628.40780.hselasky@c2i.net> In-Reply-To: <201301141628.40780.hselasky@c2i.net> Content-Type: text/plain; charset=iso-8859-15 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: Tue, 15 Jan 2013 11:28:16 -0000 Hans Petter Selasky wrote: > > Do you know what mode the chip is running in for the B-channels? Not really. > HDLC or so-called transparent mode (no bit-destuffing). By default the AVM PCI > driver is setup to use HDLC emulation, and expects that the chip is configured > for transparent mode. Valid HDLC flags start like 0x7E, and that is what I > would expect. Else something is wrong somewhere. > > [Incoming data] -> [HDLC table decoder] -> [isdndecode] > > No data in isdndecode means that the HDLC table decoder is not getting what it > expects. Thanks for this clarification. With some more initialization stolen from the BSD source I now have for the first incoming frame: avm_pci_b_status_read: len_rx=32: 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff avm_pci_b_status_read: len_rx=32: 0xffffffffffe7ff7e7edf070087043c003814183cf920021e20001ea9cfe8e7e7 avm_pci_b_status_read: len_rx=32: 0xe7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7 and the first outgoing looks like this: avm_pci_b_status_read: len_tx=32: 0xffffff7edf070087040400381418683c51db0d10008f30e0fafdffffffffffff and my local isdndecode sees both of this frames (remote isdndecode sees only his own frame): -- TE->NT - unit:00 frame:000030 - time:14.01 21:28:26.129845 - length:18 ---- B01:000 ff 03 c0 21 01 01 00 0e 05 06 1a 4f d4 76 03 04 B01:010 c0 23 -- NT->TE - unit:00 frame:000031 - time:14.01 21:28:26.203400 - length:18 ---- B01:000 ff 03 c0 21 01 0f 00 0e 05 06 4f 3e 44 c0 03 04 B01:010 c0 23 But no more frames. I have b1control=hdlc in my isdnd.rc and use for the card: isdnconfig -u 0 -p DRVR_DSS1_TE I do not know what to do otherwise from userland to "configure the chip for transparent mode". The kernel driver should do this (he sets HSCX_MODE_TRANS) ? I agree there is a communication problem for B-channel between the driver and the chip. For an outgoing B-channel frame we write the frame to the fifo of the chip but I cannot see, that we tell the chip we are ready and the frame should go out the line. For an incoming B-channel frame we read the frame from the fifo of the chip but I don't see that we tell the chip we have it, so the chip does not get the next frame from the line. For incoming D-channel frames we use RMC command for this in register cmdrd. Probably I am missing something. -- Andreas Longwitz