Date: Mon, 14 Oct 2002 23:13:05 -0700 From: Guy Harris <gharris@sonic.net> To: Harti Brandt <brandt@fokus.gmd.de> Cc: Craig Rodrigues <rodrigc@attbi.com>, freebsd-net@FreeBSD.ORG Subject: Re: How to add bpf support to if_atmsubr.c? Message-ID: <20021014231305.H332@quadrajet.sonic.net>
next in thread | raw e-mail | index | archive | help
> The problem is, that at attach time you > don't know what link-level encapsulation is used, because this can be > select when you establish the VCC (via the parameter 'z' (see en(4))). > So BPF_DLC_RFC1483 will not work without LLC/SNAP encapsulation. The current CVS versions of libpcap and tcpdump, and the current released version of Ethereal, support a DLT_SUNATM DLT_ type. SunATM's DLPI interface supplies packets with a 4-byte pseudo-header, consisting of: a 1-byte flag byte; a 1-byte VPI value; a 2-byte (big-endian) VCI value; where the flag byte contains a one-bit "direction" flag (indicating whether the packet was sent or received) and a 4-bit packet type. After that comes the raw reassembled PDU. The packet type can be one of "raw" - meaning "other"? LANE LLC-multiplexed MARS IFMP ILMI Q.2931 A similar thing could perhaps be done here; that'd allow the driver to supply signalling traffic to BPF, for example. That way, the encapsulation type - DLT_BPFATM, or something such as that - wouldn't depend on the circuit type; it'd be supplied to the application as part of the packet pseudo-header. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021014231305.H332>