[Guy Harris <guy@xxxxxxxxxx>]

> I appreciate the information, thanks.  A couple of questions though, is "
> ether[14:2] == 0xffff" what I would put into the ethereal capture filter
> string box?

Yes.  You put into that box the exact same filter string that you'd give
to tcpdump (because, assuming your tcpdump is linked with the same
libpcap library that Ethereal is, the exact same code is handling both
filter strings).

> Where do the values inside the brackets come from [14:2]?

Quoting the tcpdump man page:

	  expr relop expr
	       True if the relation holds, where relop is one  of
	       >,  <,  >=,  <=,	 =, !=,	and expr is an arithmetic
	       expression   composed   of    integer	constants
	       (expressed  in  standard	 C  syntax),  the  normal
	       binary operators	[+, -, *,  /,  &,  |],	a  length
	       operator,  and  special packet data accessors.  To
	       access data inside the packet, use  the	following
	       syntax:
		    proto [ expr : size	]
	       Proto is	one of ether, fddi, ip,	arp,  rarp,  tcp,
	       udp, or icmp, and indicates the protocol	layer for
	       the index operation.  The byte offset, relative to
	       the  indicated  protocol	 layer,	is given by expr.
	       Size is optional	and indicates the number of bytes
	       in  the	field  of interest; it can be either one,
	       two, or four, and defaults  to  one.   The  length
	       operator,  indicated by the keyword len,	gives the
	       length of the packet.

	       For example, `ether[0] &	1 != 0'	catches	all  mul-
	       ticast traffic.	The expression `ip[0] &	0xf != 5'
	       catches all IP packets with options.  The  expres-
	       sion  `ip[6:2]  & 0x1fff	= 0' catches only unfrag-
	       mented  datagrams  and  frag  zero  of  fragmented
	       datagrams.   This  check	 is implicitly applied to
	       the tcp and udp index operations.   For	instance,
	       tcp[0]  always  means  the  first  byte of the TCP
	       header, and never  means	 the  first  byte  of  an
	       intervening fragment.

So "14" is an offset relative to the beginning of the Ethernet header,
and "2" is the length of the field being checked.

The Ethernet header is 14 bytes, so this tests the first two bytes
*after* the Ethernet header.  *If* the packet is an IEEE 802.3 packet
(where the last two bytes of the Ethernet header are a length field)
rather than a Digital-Intel-Xerox Ethernet packet (where the last two
bytes of the Ethernet header are a packet type), the Ethernet header is,
in theory, followed by an IEEE 802.2 LLC header, the first two bytes of
which are a Destination Service Access Point and a Source Service Access
Point, which are sort of like packet types.

However, Netware appears to have invented their own scheme, perhaps
before the IEEE 802.2 standard came out, wherein right after the 14-byte
IEEE 802.3 header comes an IPX header, which begins with 0xFFFF.

So this particular expression is checking for the Netware-atop-raw-802.3
encapsulation, rather than Netware-atop-802.2 encapsulation.

That expression should also probably be checking for

	ether[12:2] <= 1500

so check whether the last 2 bytes of the Ethernet header are an IEEE
802.3 length field rather than a Digital-Intel-Xerox Ethernet type field
(both 802.3 and Digital-Intel-Xerox packets can be put on the same
Ethernet segment).

Don Provan of Novell once wrote a somewhat exasperated essay explaining
this mess (he was definitely in the "so what was wrong with Good Old
Digital-Intel-Xerox Ethernet, anyway?" camp).  That essay can be found
in the middle of a Novell Netware FAQ at

	http://www.seflin.org/compinfo/novell.html

(search for "metaphorically speaking", as his essay starts with:

	I'm often stopped on the street, metaphorically speaking, and
	asked, "Hey, Don, what *is* it with these Ethernet frame types."
	I've determined that the inquisitor generally wants the answer
	to one of four questions, which i list here in rough order of
	increasing inflamedness:

	1. Physically, what do the four Ethernet frame types look like?

	2. Politically, where do the four Ethernet frame types come
	   from? (Or, put more simply, "Why are there four?")

	3. If Ethernet_802.3 is so Yucky, should I stop using it?

	4. Which Ethernet frame type should I use for IPX?)

> If he value
> 0xffff will pick up IPX packets, what would the value be for NCP packets?

NCP isn't a protocol that runs as the same layer as IPX, it's a protocol
that runs *atop* IPX, so, to pick up NCP packets, you don't use a
different value there - you use that value first, and, then, for packets
that *do* have that value, you then check the fields in the IPX header
to see whether the IPX packet in question contains an NCP packet or not.

I'll let Gilbert answer that one, as he's more likely to know the right
answer off the top of his head.