Ethereal-users: Re: [ethereal-users] Ethereal don't open IBM Token-Ring Adapter 16/4

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Tue, 25 Jul 2000 23:45:13 -0700
On Mon, May 15, 2000 at 10:15:03AM -0500, Gilbert Ramirez wrote:
> Yes, that's what libpcap does. On Linux, libpcap needs a helping hand
> with token-ring.. the author of the ibmtr driver for Linux has a patch
> to libpcap that lets libpcap correctly detect a token-ring interface
> as token-ring. It's unfortunate that the label "DLT_IEEE802" is used
> as token-ring, since it really should be 802.5. I think if "802" as
> referring to the whole suite of 802.x link types.

Well, both the BSDs and Linux treat DLT_IEEE802 as Token Ring, so even
though it's *de jure* a lousy name, it's pretty much the *de facto*
standard.

The current "pcap-linux.c" in the top of the tcpdump.org tree for
libpcap turns ARPHRD_IEEE802 into DLT_IEEE802 (and so does the standard
LBL libpcap 0.4; at least in the 2.2.15 kernel, "init_trdev()" uses
ARPHRD_IEEE802, and the "ibmtr.c", "lanstreamer.c", "olympic.c", and
"sktr.c" Token Ring drivers use it in 2.2.15, so I'd expect them to be
recognized as Token Ring with vanilla libpcap).

> However, the token-ring support in libpcap is minimal. Libpcap's design
> assumes that a link layer protocol has a fixed header length. Token-ring
> does not. Libpcap assumes that token-ring headers have the minimum
> size, which means you can correctly filter on higher-layer protocols
> only if they don't involve token-ring source-routing, which gives the
> minimum-sized TR header.

Yes, the current CVS libpcap doesn't handle that (and I checked in an
entry in the BUGS section of the tcpdump man page saying so).  It'd be
nice to make it handle them, but what's checked in now is better than
nothing....

> > I think there might be Token Ring patches for libpcap and tcpdump
> > somewhere on the net, but they probably haven't yet been incorporated
> > into the tcpdump.org tree.
> 
> I think the Linux-related ones have not been incorporated.

The current tcpdump.org tree has a tcpdump that dissects Token Ring,
with a "print-token.c" that's a merger of the FreeBSD and NetBSD ones
(which resulted in a version that, I think, works better than either of
them by themselves, and better than the versions I've seen in patches;
libpcap may not filter source-routed packets correctly, but at least
tcpdump properly handles them and dumps the source route).

It also has a libpcap that handles DLT_IEEE802 as Token Ring (and lets
you use "tr" as an alias for "ether", just as it lets you use "fddi"),
and generates code filter expressions for Token Ring (albeit ones that
don't, as noted, handle source-routed packets; that'll take a bit more
work).