From owner-freebsd-net Mon Oct 14 23:13: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70F1B37B401 for ; Mon, 14 Oct 2002 23:13:08 -0700 (PDT) Received: from a.smtp-out.sonic.net (a.smtp-out.sonic.net [208.201.224.38]) by mx1.FreeBSD.org (Postfix) with SMTP id E1AB343EAA for ; Mon, 14 Oct 2002 23:13:07 -0700 (PDT) (envelope-from gharris@sonic.net) Received: (qmail 15087 invoked from network); 15 Oct 2002 06:13:06 -0000 Received: from ultra.sonic.net (208.201.224.22) by a.smtp-out.sonic.net with SMTP; 15 Oct 2002 06:13:06 -0000 Received: from quadrajet.sonic.net (adsl-209-204-185-65.sonic.net [209.204.185.65]) by ultra.sonic.net (8.11.6/8.8.5) with ESMTP id g9F6D6r10999; Mon, 14 Oct 2002 23:13:06 -0700 X-envelope-info: Received: (from guy@localhost) by quadrajet.sonic.net (8.9.3/8.9.3) id XAA88478; Mon, 14 Oct 2002 23:13:05 -0700 (PDT) (envelope-from gharris) Date: Mon, 14 Oct 2002 23:13:05 -0700 From: Guy Harris To: Harti Brandt Cc: Craig Rodrigues , freebsd-net@FreeBSD.ORG Subject: Re: How to add bpf support to if_atmsubr.c? Message-ID: <20021014231305.H332@quadrajet.sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > 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