From owner-freebsd-atm@FreeBSD.ORG Wed Mar 9 09:51:46 2011 Return-Path: Delivered-To: freebsd-atm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40AD9106566C; Wed, 9 Mar 2011 09:51:46 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id A27918FC16; Wed, 9 Mar 2011 09:51:45 +0000 (UTC) Received: from DLREXHUB02.intra.dlr.de (172.21.152.140) by mailhost.dlr.de (172.21.163.100) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 9 Mar 2011 10:40:48 +0100 Received: from beagle.kn.op.dlr.de (129.247.178.136) by smtp.dlr.de (172.21.152.151) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 9 Mar 2011 10:40:52 +0100 Date: Wed, 9 Mar 2011 10:40:50 +0100 From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Martin Birgmeier In-Reply-To: <4D5FD039.9000706@aon.at> Message-ID: <20110309103113.W92621@beagle.kn.op.dlr.de> References: <4D5FD039.9000706@aon.at> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [129.247.178.136] Cc: freebsd-atm@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Vote in favor of keeping ATM (was: NATM still scheduled for removal - please follow up to keep it in-tree) X-BeenThere: freebsd-atm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: ATM for FreeBSD! List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 09:51:46 -0000 Hi Martin, On Sat, 19 Feb 2011, Martin Birgmeier wrote: MB>p.s. A few :-) of the questions I have are MB> MB>- why the original (as I understand HARP) ATM stack was removed (in the CVS MB>logs the reason cited is the usual giant lock issue of that time), This is one reason. Another problem was, that HARP was a rather umaintainable monolithic block of code. Many years ago I needed to do modifications in the ATM signaling and that was just impossible. So I decided to build all the stuff on NATM which rather nicely fits into the socket framework. MB>- what the differences between the atm and natm stacks are (as I understand MB>the latter only supports a subset of the functionality of the former - only MB>AAL5?), NATM is a very thin layer to be able to use VCIs directly in an application. All the stuff in ng_atm can be used together with NATM and provides a modular framework for doing ATM work. There are missing pieces like CLIP and a decent connection of the ATM signaling to the socket interface, but my interest in this dropped because ATM is basically given up by industry. Except for the use in ADSL (which is slowly phased out by the new DSL standards) it is dead. MB>- why AF_NATM is different from AF_ATM (hinting that NATM is not a MB>replacement of ATM), AF_NATM allows you to bind VCIs with AAL5 or AAL0 (raw cells). AF_ATM had also an ad-hoc interface to signaling. MB>- whether and how it is even possible to inject raw ATM cells, AF_NATM with AAL0. MB>- whether I even need "options NATM" (currently I can happily instantiate a MB>(of course non-functional) ATM interface using just "device atm"), Since time has passed I'm not sure on this. You need optiosn NATM either to do IP over ATM directly or to get the AF_NATM stuff. Don't remember, sorry. MB>- what do I need to do on the USB side to start receive and transmit machines MB>(do I need to start separate kernel threads or just issue two MB>usbd_transfer_setup() calls as for loading the firmware), I'v no idea on this. I would suppose, that your driver would appear to the atm stack as an ATM interface, right? MB>I do of course read the source, but with the scarce documentation available MB>that's a steep learning curve. You may try to look up the original paper on NATM - its a nice reading as far as I remember... harti From owner-freebsd-atm@FreeBSD.ORG Wed Mar 9 17:21:50 2011 Return-Path: Delivered-To: freebsd-atm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3335C1065673 for ; Wed, 9 Mar 2011 17:21:50 +0000 (UTC) (envelope-from la5lbtyi@aon.at) Received: from email.aon.at (nat-warsl417-01.aon.at [195.3.96.119]) by mx1.freebsd.org (Postfix) with ESMTP id 875E98FC1B for ; Wed, 9 Mar 2011 17:21:49 +0000 (UTC) Received: (qmail 1603 invoked from network); 9 Mar 2011 17:21:47 -0000 Received: from smarthub96.highway.telekom.at (HELO email.aon.at) ([172.18.5.235]) (envelope-sender ) by fallback43.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 9 Mar 2011 17:21:47 -0000 Received: (qmail 7811 invoked from network); 9 Mar 2011 17:21:45 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on WARSBL603.highway.telekom.at X-Spam-Level: Received: from 91-113-3-45.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([91.113.3.45]) (envelope-sender ) by smarthub96.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 9 Mar 2011 17:21:45 -0000 Received: from atpcdvvc.xyzzy (atpcdvvc.xyzzy [IPv6:fec0:0:0:4d42::84]) by gandalf.xyzzy (8.14.4/8.14.4) with ESMTP id p29HLjtC014872; Wed, 9 Mar 2011 18:21:45 +0100 (CET) (envelope-from la5lbtyi@aon.at) Message-ID: <4D77B729.6010309@aon.at> Date: Wed, 09 Mar 2011 18:21:45 +0100 From: Martin Birgmeier User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.15) Gecko/20110305 Thunderbird/3.1.9 MIME-Version: 1.0 To: Harti Brandt References: <4D5FD039.9000706@aon.at> <20110309103113.W92621@beagle.kn.op.dlr.de> In-Reply-To: <20110309103113.W92621@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Harti Brandt , freebsd-atm@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Vote in favor of keeping ATM X-BeenThere: freebsd-atm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ATM for FreeBSD! List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 17:21:50 -0000 Hi Harti, Thanks for your pointers. On 03/09/11 10:40, Harti Brandt wrote: > Hi Martin, > > On Sat, 19 Feb 2011, Martin Birgmeier wrote: > [...] > > MB>- whether and how it is even possible to inject raw ATM cells, > > AF_NATM with AAL0. > > MB>- whether I even need "options NATM" (currently I can happily instantiate a > MB>(of course non-functional) ATM interface using just "device atm"), > > Since time has passed I'm not sure on this. You need optiosn NATM either > to do IP over ATM directly or to get the AF_NATM stuff. Don't remember, > sorry. From looking at the source I believe "options NATM" might only be needed to do IP over ATM directly. Specifically, routing information seems to be stored somewhere (this is where "options NATM" currently breaks). However, I have no idea what one actually gets with just "device atm" but no "options NATM". As I said, I can do atm_ifattach() successfully, but don't currently know what that really accomplishes. I do not need IP over ATM, but rather need PPPoA. For this, I need to extract the raw PPP frames either directly, or from their LLC encapsulation, as per RFC2364. That I want to do via netgraph, specifically by expanding the functionality of the ng_atmllc node to also treat LLC/ISO, thereby turning ng_atmllc into "ng_llc" (RFC2684). > > MB>- what do I need to do on the USB side to start receive and transmit machines > MB>(do I need to start separate kernel threads or just issue two > MB>usbd_transfer_setup() calls as for loading the firmware), > > I'v no idea on this. > > I would suppose, that your driver would appear to the atm stack as an ATM > interface, right? That question was in fact more directed to Hans-Petter, and he has already answered it. But regarding your question, I simply don't yet know enough about the ATM stack. The only thing I know is that I can get raw ATM cells out of and into the USB interface/ADSL line, but I do not know how to make this meaningful to the current ATM stack. I probably need to do the AAL5 SAR myself, because from looking at the drivers (fatm, hatm, etc.) I have the impression that this is something which is normally handled by the hardware itself (does the hardware know how to handle either AAL0 or AAL5, doing SAR for the latter? And for AAL0, what do I get on a socket read/write? - One ore multiple cells? - Same for AAL5 - do I get one or may I also get multiple packets?). I'd also be interested in understanding how I might be able to handle signaling information arriving over the ADSL line - I believe this does sometime happen. > > MB>I do of course read the source, but with the scarce documentation available > MB>that's a steep learning curve. > > You may try to look up the original paper on NATM - its a nice reading as > far as I remember... > > harti > Regards, Martin