From owner-freebsd-atm@FreeBSD.ORG Mon Feb 14 17:10:07 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 BA759106564A; Mon, 14 Feb 2011 17:10:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 495318FC0A; Mon, 14 Feb 2011 17:10:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3679941C7A6; Mon, 14 Feb 2011 18:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id jh-nA9ITjuLM; Mon, 14 Feb 2011 18:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id C392241C7AF; Mon, 14 Feb 2011 18:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1C59B4448F3; Mon, 14 Feb 2011 17:07:49 +0000 (UTC) Date: Mon, 14 Feb 2011 17:07:49 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org, freebsd-atm@freebsd.org Message-ID: <20110214170214.Y13400@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: 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 List-Id: ATM for FreeBSD! List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 17:10:07 -0000 Hi, now that stable/8 (not part of the upcoming 8.2-R) once again has support for NATM I'd like to remind people of http://lists.freebsd.org/pipermail/freebsd-net/2010-December/027215.html especially: :: 1) the extra couple of months; this will not prevent the evitable removal :: yet only defer it. :: :: 2) If anyone of you is using (or want to be able to (continue to) use) NATM :: or can test things, I re-enabled it with most of the code in HEAD and :: the patch is available for 8,x as well but need to work with somoene :: to make sure it'll really work. I am willing to spend more time on it :: if you send me an email. So if anyone of you is still using NATM, please follow-up with me to keep your functionality. If there is no feedback NATM is still scheduled for removal. Thank you. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ---------- Forwarded message ---------- Date: Mon, 14 Feb 2011 16:54:03 +0000 (UTC) From: Bjoern A. Zeeb To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-8@freebsd.org Subject: svn commit: r218684 - in stable/8/sys: conf netinet Author: bz Date: Mon Feb 14 16:54:03 2011 New Revision: 218684 URL: http://svn.freebsd.org/changeset/base/218684 Log: MFC r216466: Bring back (most of) NATM to avoid further bitrot after r186119. Keep three lines disabled which I am unsure if they had been used at all. This will allow us to seek testers and possibly bring it all back. Discussed with: rwatson Modified: stable/8/sys/conf/NOTES stable/8/sys/netinet/if_atm.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) From owner-freebsd-atm@FreeBSD.ORG Sat Feb 19 14:41:02 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 DB5041065670 for ; Sat, 19 Feb 2011 14:41:01 +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 3BAC48FC1D for ; Sat, 19 Feb 2011 14:41:00 +0000 (UTC) Received: (qmail 16983 invoked from network); 19 Feb 2011 14:14:20 -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 ; 19 Feb 2011 14:14:20 -0000 Received: (qmail 29696 invoked from network); 19 Feb 2011 14:14:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on WARSBL603.highway.telekom.at X-Spam-Level: Received: from 178-191-94-218.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([178.191.94.218]) (envelope-sender ) by smarthub96.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 19 Feb 2011 14:14:18 -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 p1JEEHPm025586; Sat, 19 Feb 2011 15:14:18 +0100 (CET) (envelope-from la5lbtyi@aon.at) Message-ID: <4D5FD039.9000706@aon.at> Date: Sat, 19 Feb 2011 15:14:17 +0100 From: Martin Birgmeier User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.16) Gecko/20101219 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-atm@freebsd.org, freebsd-usb@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 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 List-Id: ATM for FreeBSD! List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 14:41:02 -0000 Hi, I would like to vote in favor of keeping NATM in the kernel. The reason is that I am currently working on writing a device driver for the SpeedTouch USB modem, to replace ports/net/pppoa which is not supported on FreeBSD8+ any more. The SpeedTouch USB in fact terminates as an ATM connection, on top of which PPPoA needs to be layered. From my experiments with compiling a kernel with "device atm" and "options NATM", I know that currently only the former works, this being due to unmaintained and broken code dealing with routing entries. I am currently not much of a kernel code expert, but have already managed to write enough of the USB side of the device driver to load the modem's firmware. The next step would be to connect it to the ATM stack, using this route: 1. Terminate as ATM interface (ATM cells arriving); 2. The ATM stack implements AAL5 (I hope); 3. Capture the interface via ng_atm (which, as far as I understand, would more aptly be named ng_natm); 4. Extend the functionality of ng_atmllc (which basically does a small subset of RFC2684) to also do LLC/ISO (cf. RFC2364) (then better named ng_llc); 5. Couple the resultant PPP stream to ng_ppp; 6. Use something to configure the VPI/VCI (what?); 7. Run ports/net/mpd5 on that netgraph node. 5. and 7. could be replaced by ng_tty and ppp(8), but that would be the poorer choice as all traffic would have to go through userland again as it is doing with ports/net/pppoa. For this I'd need a) a working ATM stack and b) the help of some kind souls in hooking everything up. Hans-Petter Selasky has already been very helpful with the USB part in private mail, and I actually wanted to solicit more help on the networking side of things privately in order not to trumpet out something which I'll probably finish only after considerable time, but reading the removal message I felt that I needed to make my needs public. Regards, Martin p.s. A few :-) of the questions I have are - why the original (as I understand HARP) ATM stack was removed (in the CVS logs the reason cited is the usual giant lock issue of that time), - what the differences between the atm and natm stacks are (as I understand the latter only supports a subset of the functionality of the former - only AAL5?), - why AF_NATM is different from AF_ATM (hinting that NATM is not a replacement of ATM), - whether and how it is even possible to inject raw ATM cells, - whether I even need "options NATM" (currently I can happily instantiate a (of course non-functional) ATM interface using just "device atm"), - what do I need to do on the USB side to start receive and transmit machines (do I need to start separate kernel threads or just issue two usbd_transfer_setup() calls as for loading the firmware), - etc. etc. I do of course read the source, but with the scarce documentation available that's a steep learning curve. -- Martin Birgmeier Vienna Austria From owner-freebsd-atm@FreeBSD.ORG Sat Feb 19 14:54:23 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 83FBE1065672 for ; Sat, 19 Feb 2011 14:54:23 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 1183E8FC0C for ; Sat, 19 Feb 2011 14:54:22 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=O4luLtK3s/BI/ZI2MixGyL7hJC8Dk2jKRuc55HZ6Kk0= c=1 sm=1 a=lOKV7v79jiQA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Kh5ckXmFqLo-T-vMrQwA:9 a=pyRnSkCCCumXsdZhgu8A:7 a=hYig6YFvJg4971TPZC80WkzzZt4A:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 89077956; Sat, 19 Feb 2011 15:44:19 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 19 Feb 2011 15:44:06 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <4D5FD039.9000706@aon.at> In-Reply-To: <4D5FD039.9000706@aon.at> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102191544.06972.hselasky@c2i.net> Cc: freebsd-atm@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 List-Id: ATM for FreeBSD! List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 14:54:23 -0000 On Saturday 19 February 2011 15:14:17 Martin Birgmeier wrote: > - what do I need to do on the USB side to start receive and transmit > machines (do I need to start separate kernel threads or just issue two > usbd_transfer_setup() calls as for loading the firmware), USB already has some kernel threads which all callbacks are executed from. If your software does not sleep I.E. pause() in the callbacks, then it should be OK to execute the ATM stack directly from USB. --HPS