Ethereal-users: Re: [ethereal-users] How to set capture filter for IPX and NCP (Novell)?
> Can anyone tell me how to setup capture filters to only pickup IPX/NCP
> packets?
Unfortunately, the "libpcap" library doesn't have any support for IPX,
making it a bit difficult to filter on the contents of the IPX portion
of the packet, much less the NCP portion.
You might have to do something *really* gross, and construct a filter
that looks at bytes at a particular offset into the packet, using the
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 proto-
col 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
multicast traffic. The expression `ip[0] &
0xf != 5' catches all IP packets with
options. The expression `ip[6:2] & 0x1fff =
0' catches only unfragmented 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.
mechanism (where it'd presumably be "ether[X:Y]", as it looks as if the
traffic you're capturing is Ethernet traffic).
Alas, there's no nicer way to do it that I know of (and I'm not an IPX
expert, so I don't know the offsets - you can probably get them by
looking at the packet in question).
Note that all arithmetic and comparisons done on 2-byte or 4-byte
quantities by the BPF engine that "libpcap" uses are big-endian.
"packet-ipx.c" seems to imply that IPX fields are big-endian (perhaps
Xerox's XNS protocols, upon which many Novell protocols were based, were
big-endian, so they went big-endian even though Novell stuff generally
runs on little-endian machines), and "packet-ncp.c" seems to imply that
NCP fields are big-endian as well, so you may be in luck there.
If, as, and when we finally get Wiretap to the point where it can
completely replace "libpcap", we should be able to give it the ability
to specify IPX, NCP, etc. filters somewhat more conveniently (as well as
giving it a capture-filter syntax more closely resembling that of
display filters, obviating the need for the damn Linux patch, giving it
the ability to capture on more than one interface, giving it a native
capture file format without the limitations of "libpcap"s, etc., etc.,
etc.).
