Ethereal-users: Re: [Ethereal-users] unsupported Ethernet type 10

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

From: Guy Harris <guy@xxxxxxxxxx>
Date: Thu, 5 Dec 2002 13:19:03 -0800
On Thu, Dec 05, 2002 at 08:24:51PM +0100, EXT / SITICOM KURZWEG wrote:
> OK, I've been able to reproduce the issue. It actually doesn't depend on
> whether I'm using 0.9.4 or 0.9.7 but on the particular capture file I'm
> trying to open. Some files open normally; for others, I get error "snoop:
> network type 10 unknown or unsupported".
> 
> Attached are 2 files (generated using the same Optiview device), one which
> opens OK, the other for which I get the error.

That's odd, because both of them have a version number of 2 (which is
the number used by snoop as well as by Shomiti's software when *not*
using their special hardware stuff), but have *different* link-layer
type numbers!

The one that doesn't get the error has a type number of 4, which is
DL_ETHER in

	http://www.opengroup.org/onlinepubs/9638599/apdxf.htm

i.e., it's the DLPI DL_ value for Ethernet.

The one that *does* get the error has a type number of 10, which is
DL_FRAME in that file - DL_FRAME isn't documented in RFC 1761, so the
Shomiti people may have assumed that it was OK to hijack a number of 10
for their own purposes.

According to

	http://web.archive.org/web/20010906213807/http://www.shomiti.com/support/TNCapFileFormat.htm

4 is SNOOP_ETHERNET and 10 is SNOOP_FAST_ETHERNET; was the device on
which the capture was done attached to different networks at the times
you did the two captures, one a 10Mb/s Ethernet and one a 100Mb/s
Ethernet?  If not, I have no idea why it provided two different
link-layer types.

As I've not yet seen a Frame Relay capture from snoop or any snoop
derivative, I will, for now, make Ethereal's capture-reading library
interpret 10 as Ethernet (it currently rejects it, as, not having seen a
Frame Relay snoop capture, I don't know whether such a capture would,
*if* it existed, use the same encapsulation as other Frame Relay
captures or not).  If somebody complains that their snoop Frame Relay
capture is misinterpreted as an Ethernet capture by Ethereal, we'll have
to figure out some heuristic to figure out whether a capture with a
version number of 2 and a link-layer type of 10 came from snoop or some
Shomiti-flavored capture program or device, e.g. seeing whether the
first frame in the capture has more than 3 bytes of padding or not (more
than 3 bytes means it's not all padding, as snoop only pads to 4-byte
boundaries, which means it's probably a Shomiti-flavored capture with
the extra Shomiti information hidden in the capture).

Of course, Shomiti's decision to use 10 rather than 4 for fast Ethernet
captures means that snoop can't read those captures, the fact that they
tried to hide their additional stuff in padding that snoop would ignore
nonwithstanding:

	hostname$ snoop -i ~/captures/shomiti/pkts_01-06-99_02_04.cap 
	snoop: Mac Type = a is not supported

but I guess that's their problem.