(LBL aren't maintaining libpcap or tcpdump any more; it's now being
handled by tcpdump.org:
http://www.tcpdump.org/
Mail to "[EMAIL PROTECTED]" and "[EMAIL PROTECTED]" is forwarded to
"[EMAIL PROTECTED]"; I'm replying to the latter address.)
On Tue, Feb 26, 2002 at 05:05:26PM -0800, Dan Clark wrote:
> Short term, however, the handling of both bridged and routed rfc1483
> (which is obsoleted by rfc2684 btw) is clearly desirable. Based on the
> code in libpcap/gencode.c a new flag would be required to fix the
> constants for off_linktype and off_nl used by the filtering code which
> suggests the definition of a new DLT flag, such as:
> case DLT_ATM_RFC2684:
> /*
> * assume bridged pdus
> * (i.e., LLC = 0xAA-AA-03, OUI = 0x00-80-c2)
> */
> off_linktype = 22;
> off_nl = 24;
> return;
> case DLT_ATM_RFC1483:
> /*
> * assume routed, non-ISO PDUs
> * (i.e., LLC = 0xAA-AA-03, OUT = 0x00-00-00)
> */
> off_linktype = 6;
> off_nl = 8;
> return;
That's one possibility (although the name DLT_ATM_RFC2684 is misleading,
as routed, non-ISO PDUs are *also* RFC 2684 PDUs; I'd be tempted to use
names such as DLT_ATM_RFC2684_BRIDGED and DLT_ATM_RFC2684_ROUTED, the
latter being the same as DLT_ATM_RFC1483).
Another possibility might be to have, for example, DLT_LLC, which merely
assumes that the packet begins with an 802.2 LLC header; it could
generate code that checks for routed NLPID-formatted PDUs, routed
SNAP-encapsulated PDUs, and bridged PDUs. (We could then conceivably
use the same stuff for link layers that put 802.2 LLC headers on top of
the MAC headers.)
> Although clearly it would be better to handle both flexibly as is possible
> under tcpdump/print-atm.c by examining the
> LLC and the OUI
> if ! LLC == 0xaa-aa-03
> dump this strange packet
> if OUI == 0x00-00-00
> then routed
> else if OUI == 0x00-80-c2
> then bridged
The *right* way to handle that would be to
1) add support for RFC 2684 bridged encapsulation to
"print-llc.c";
2) just have "atm_if_print()" call "llc_print()".
> The identification of signalling and ilmi traffic, without a priori
> knowledge of the VC's for the traffic, would be difficult but perhaps
> possible?
Is there any case where you would see signalling or ILMI traffic if the
driver for the device on which you're capturing uses DLT_ATM_RFC1483 (or
DLT_ATM_RFC2684_BRIDGED, or DLT_ATM_RFC2684_ROUTED)?
If so, I'd consider that a driver bug. The driver *should*, if it's
going to supply traffic other than RFC 2684 LLC-encapsulated packets to
the capture device/socket/whatever, use an encapsulation in which it
supplies some sort of AAL5 pseudo-header, including the VPI and VCI, and
should use some other DLT_ value, e.g. a new DLT_ATM_AAL5 DLT_ value.
It'd be nice if it could also supply other information indicating the
type of traffic.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
