Date: Thu, 15 Jun 2000 21:31:19 -0700 From: Guy Harris <gharris@flashcom.net> 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>
next in thread | raw e-mail | index | archive | help
(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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000615213119.D351>