From owner-freebsd-atm Tue Jun 13 20:32:40 2000 Delivered-To: freebsd-atm@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 1525A37BB3B for ; Tue, 13 Jun 2000 20:32:37 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id WAA95592 for freebsd-atm@freebsd.org; Tue, 13 Jun 2000 22:37:14 -0500 (CDT) From: Joe Greco Message-Id: <200006140337.WAA95592@aurora.sol.net> Subject: HARP and BPF To: freebsd-atm@freebsd.org Date: Tue, 13 Jun 2000 22:37:14 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-atm@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So, I was curious if there is any current development on the HARP stuff, and if so, might BPF be something that will be supported? Drives me nuts that I can't tcpdump on my WAN links. :-) Thanks, -- ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message From owner-freebsd-atm Wed Jun 14 7:13: 5 2000 Delivered-To: freebsd-atm@freebsd.org Received: from marcos.networkcs.com (marcos.networkcs.com [137.66.16.1]) by hub.freebsd.org (Postfix) with ESMTP id C918837C16E for ; Wed, 14 Jun 2000 07:13:01 -0700 (PDT) (envelope-from jpt@us.networkcs.com) Received: from us.networkcs.com (us.networkcs.com [137.66.11.15]) by marcos.networkcs.com (8.9.3/8.9.3) with ESMTP id JAA89350; Wed, 14 Jun 2000 09:13:00 -0500 (CDT) (envelope-from jpt@us.networkcs.com) Received: (from jpt@localhost) by us.networkcs.com (8.9.2/8.9.2) id JAA14888; Wed, 14 Jun 2000 09:13:00 -0500 (CDT) (envelope-from jpt) From: Joseph Thomas Message-Id: <200006141413.JAA14888@us.networkcs.com> Subject: Re: HARP and BPF To: jgreco@ns.sol.net (Joe Greco) Date: Wed, 14 Jun 2000 09:13:00 -0500 (CDT) Cc: freebsd-atm@FreeBSD.ORG In-Reply-To: <200006140337.WAA95592@aurora.sol.net> from "Joe Greco" at Jun 13, 2000 10:37:14 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-atm@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > So, I was curious if there is any current development on the HARP stuff, > and if so, might BPF be something that will be supported? > > Drives me nuts that I can't tcpdump on my WAN links. :-) > > Thanks, > -- > ... Joe > > ------------------------------------------------------------------------------- > Joe Greco - Systems Administrator jgreco@ns.sol.net > Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 We (the HARP developers) have a list of many things we'd like to do however, we currently have no funding for any continued HARP work and is typical of most people, must concentrate on what we are being paid to do. As such, no, we don't have any plans to do new HARP work such as BPF. That being said, adding BPF at the IP level can be considered a trivial task... I think literally less than one dozen lines of code. What's harder, and I admit that I haven't been following the tcpdump et. al. discussions, is adding ATM support. That is, passing info such as VPI/VCI so that one could say, decode UNI messages as well as IP traffic. You could take a look at most any if_* driver with BPF and then look at /usr/src/sys/netatm/ipatm/{ipatm_input.c,ipatm_output.c}. -- Joseph Thomas E/Mail: jpt@networkcs.com Network Computing Services, Inc. jpt@magic.net 1200 Washington Ave So. Tel: +1 612 337 3558 Minneapolis, MN 55415-1227 FAX: +1 612 337 3400 An elephant is a mouse with an operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message From owner-freebsd-atm Wed Jun 14 7:48:48 2000 Delivered-To: freebsd-atm@freebsd.org Received: from plains.NoDak.edu (plains.NoDak.edu [134.129.111.64]) by hub.freebsd.org (Postfix) with ESMTP id C71E737C1F4 for ; Wed, 14 Jun 2000 07:48:45 -0700 (PDT) (envelope-from tinguely@plains.NoDak.edu) Received: (from tinguely@localhost) by plains.NoDak.edu (8.9.3/8.9.3) id JAA27074; Wed, 14 Jun 2000 09:48:44 -0500 (CDT) Date: Wed, 14 Jun 2000 09:48:44 -0500 (CDT) From: Mark Tinguely Message-Id: <200006141448.JAA27074@plains.NoDak.edu> To: jgreco@ns.sol.net, jpt@networkcs.com Subject: Re: HARP and BPF Cc: freebsd-atm@FreeBSD.ORG Sender: owner-freebsd-atm@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > That being said, adding BPF at the IP level can be considered > a trivial task... I think literally less than one dozen lines of code. > What's harder, and I admit that I haven't been following the tcpdump > et. al. discussions, is adding ATM support. That is, passing info > such as VPI/VCI so that one could say, decode UNI messages as well > as IP traffic. > > You could take a look at most any if_* driver with BPF and then > look at /usr/src/sys/netatm/ipatm/{ipatm_input.c,ipatm_output.c}. he could also look at the BPF additions to the IDT NICStAR ATM driver and the associated atmdump program from: ftp://ftp.cs.ndsu.nodak.edu/pub/freebsd/atm/nicstar.tgz ftp://ftp.cs.ndsu.nodak.edu/pub/freebsd/atm/atm-bpf.tgz the BPF adddition could go into any other ATM driver. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message From owner-freebsd-atm Thu Jun 15 21:30: 8 2000 Delivered-To: freebsd-atm@freebsd.org Received: from c014.sfo.cp.net (c014-h017.c014.sfo.cp.net [209.228.12.81]) by hub.freebsd.org (Postfix) with SMTP id B25C937BBF0 for ; Thu, 15 Jun 2000 21:29:49 -0700 (PDT) (envelope-from gharris@flashcom.net) Received: (cpmta 20845 invoked from network); 15 Jun 2000 21:29:48 -0700 Received: from d8c81e5f.dsl.flashcom.net (HELO quadrajet.flashcom.com) (216.200.30.95) by smtp.flashcom.net (209.228.12.81) with SMTP; 15 Jun 2000 21:29:48 -0700 X-Sent: 16 Jun 2000 04:29:48 GMT Received: (from guy@localhost) by quadrajet.flashcom.com (8.9.3/8.9.3) id VAA02043; Thu, 15 Jun 2000 21:31:19 -0700 (PDT) (envelope-from gharris) Date: Thu, 15 Jun 2000 21:31:19 -0700 From: Guy Harris To: tinguely@plains.NoDak.edu Cc: jgreco@ns.sol.net, jpt@networkcs.com, freebsd-atm@FreeBSD.ORG Subject: Re: HARP and BPF Message-ID: <20000615213119.D351@quadrajet.flashcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6us Sender: owner-freebsd-atm@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (Speaking here not as an ATM developer - not surprising, as I'm *not*, and have never been, an ATM developer - but as an Ethereal developer: http://ethereal.zing.org/ and as an occasional libpcap/tcpdump developer.) Joseph Thomas writes: > That being said, adding BPF at the IP level can be considered > a trivial task... I think literally less than one dozen lines of code. > What's harder, and I admit that I haven't been following the tcpdump > et. al. discussions, is adding ATM support. That is, passing info > such as VPI/VCI so that one could say, decode UNI messages as well > as IP traffic. The way that various OSes hand ATM "frames" (which I think generally means "AAL5 frames", although I seem to remember that FORE SPANS may use a different AAL, maybe AAL4) up to whatever native packet-capture mechanism the OS provides varies from OS to OS. I infer from the contents of a Solaris "atmsnoop" capture I downloaded from somewhere that it hands up a frame consisting of a "pseudo-header" containing: one byte of "stuff", which I think includes a "DTE->DCE vs. DCE->DTE" bit; one byte of VPI; two bytes of VCI; followed by the frame data. Mark Tinguely writes: > he could also look at the BPF additions to the IDT NICStAR ATM driver > and the associated atmdump program from: The "CHANGES.ATM" file in the "atmdump" directory says that the NICStAR driver hands up a pseudo-header with: one byte of direction; one byte of VPI; two bytes of FCI; one byte of GFC, PT, and CLP; followed by the frame data. It says that Solaris (at least with the SunATM version they had) works as described above. I haven't looked at the Linux for ATM stuff in detail, but it appears, from the patch they supply to libpcap and tcpdump, sometimes to supply an RFC 1483 LLC header followed by a frame, and sometimes to supply a raw IP frame. The Midway ENI155 driver in FreeBSD 3.4 *appears* to strip off the ATM pseudo-header: #if NBPFILTER > 0 if (ifp->if_bpf) { /* * adjust the top of the mbuf to skip the pseudo atm header * (and TBD, if present) before passing the packet to bpf, * restore it afterwards. */ int size = sizeof(struct atm_pseudohdr); if (launch.atm_flags & EN_OBHDR) size += MID_TBD_SIZE; launch.t->m_data += size; launch.t->m_len -= size; BPF_MTAP(ifp, launch.t); launch.t->m_data -= size; launch.t->m_len += size; } #endif /* NBPFILTER > 0 */ before handing to BPF frames it's transmitting, and *appears* not to supply the pseudo-header when handing to BPF frames it's received: } else if (m != NULL) { ATM_PH_FLAGS(&ah) = sc->rxslot[slot].atm_flags; ATM_PH_VPI(&ah) = 0; ATM_PH_SETVCI(&ah, sc->rxslot[slot].atm_vci); #ifdef EN_DEBUG printf("%s: rx%d: rxvci%d: atm_input, mbuf %p, len %d, hand %p\n", sc->sc_dev.dv_xname, slot, sc->rxslot[slot].atm_vci, m, EN_DQ_LEN(drq), sc->rxslot[slot].rxhand); #endif ifp = &sc->enif; ifp->if_ipackets++; #if NBPFILTER > 0 if (ifp->if_bpf) BPF_MTAP(ifp, m); #endif atm_input(ifp, &ah, m, sc->rxslot[slot].rxhand); } Ethereal has no problem decoding frames with direction+VPI+VCI followed by frame data; the stuff to handle that (pseudo-header dissection, LANE dissection, ILMI dissection by the cheap expedient of handing the frame to the SNMP dissector, SSCOP and Q.2931 dissection) was originally done when I added support for reading ATM Sniffer captures, but it's also used for reading AIX iptrace captures and atmsnoop captures, and could also be used for any tcpdump-style captures (which would also let Ethereal capture ATM traffic in that fashion itself). What I would personally prefer, as an Ethereal developer, would be to have BPF on ATM supply, for all frames, a pseudo-header that includes at least a direction flag and the VPI and VCI. This would require that a new DLT_ value be assigned to that sort of "raw ATM" BPF (DLT_ATM_RFC1483 assumes that RFC 1483 LLC encapsulation is being used, and that the frame begins with an LLC header; DLT_ATM_CLIP, as added by the Linux ATM patches, appears to assume that either an LLC header or no header is at the beginning of the frame), and that the atmdump stuff be merged into tcpdump. It'd be nice if libpcap handled both DLPI-on-Solaris ATM and BPF-on-BSD ATM in such a fashion that the differences between their pseudo-headers were hidden, with the same pseudo-header (perhaps with some fields left blank if necessary, or with fields present only in some native pseudo-headers omitted) supplied to libpcap's caller and written to capture files. Note that tcpdump and libpcap are currently in the hands of tcpdump.org: http://www.tcpdump.org/ and are under fairly active development. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message