On Thu, Oct 31, 2002 at 11:38:31AM -0600, Justin Funke wrote:
> I am working with tethereal to sniff IPX traffic on a logging server
> attached in front of a Netware 4 server. What we were hoping to achieve
> is to capture the first part of the packets so we would have an
> independent system logging file access on the server.
>
> Everything is working ok but it seems we can't both decode IPX traffic
> and limit the size of the packet captured.
> This is the command we have been working with...
> tethereal -i dc0 -q -s 64 -x -F ngwsniffer_2_0 -w /usr/ipx64.cap &
What do you mean by "can't decode IPX traffic"?
What happens with the IPX traffic when you read that capture file with
Ethereal (or Tethereal) - or with the Sniffer software for Windows -
later?
If you're capturing on an Ethernet, the Ethernet header is 14 bytes, and
the IPX header is 30 bytes, so whatever packet analyzer you use should
be able to dissect that, at least.
However...
> What we want to mimic is an "ngrep" type effect where we can decode the
> traffic and capture just enough of the packet to know the originating
> address and the file they were viewing.
...if you want to know what file they were viewing, it needs to dissect
*NCP* traffic - i.e., it has to dissect not just the IPX header, but
enough of the NCP header to show information about the file.
Unfortunately, to do *that*, it appears you need more than the 64 bytes
you've requested with "-s 64" - at least in one capture, an NCP
"Open/Create File or Subdirectory" has 62 bytes of *NCP* message in it,
so that'd be 14+30+62 = 106 bytes, and a longer file name might require
more data.
> The problem is that it seems if
> we decode the traffic it wants to capture the entire packet
I assume you meant "in order to decode the traffic we need to capture
the entire packet" - it's not as if there's some flag to enable decoding
that automatically causes more data to be captured.
