On Thu, May 23, 2002 at 03:01:50PM +0200, Gonzalo Joaquin Araluce Goyoaga wrote:
> 2) ethereal:When I try to capture with a filter the /dev/lan0 CLNP
> traffic,I put a filter like clnp.nlpi == 0x81, I get a error windows the
> error : ! %s (I guess there is a problem whith the error message)
Yes, the incorrectly-displayed error message was the result of a bug
that I think we fixed in a later release; the current release is 0.9.4,
and should have that fixed.
> If I just put clnp ,it works, but ,amazing thing ,just the incoming
> traffic .
That's an HP-UX problem. If you built Ethereal from source, see the
"README.hpux" file in the source tree; look for section 5 "HP-UX patches
to fix packet capture problems" in that file for instructions on how to
get HP-UX to provide outgoing packets to packet sniffers. (On HP-UX
10.20, you need patches from HP; I don't know the numbers of those
patches - that file gives patch numbers, but they might have been
superseded with later patches.)
> With rethereal:
> tethereal -i lan0 -f "clnp.nlpi == 0x81" -w myfile.out
> Error:Unable to parse filter string
That's a valid *display* filter string; it's not a valid *capture*
filter string. Display filters and capture filters do not have the same
syntax:
http://www.ethereal.com/faq.html#q4.3
The valid *capture* filter strings are those documented by the man page
for version of tcpdump that was released along with the version of
libpcap you're using.
0x81 is the NLPID value for CLNP; the libpcap capture filter for CLNP,
in sufficiently recent versions of libpcap, is "iso proto clnp" - which
can be abbreviated as "clnp", as you've discovered.
Note that "clnp" is also a valid *display* filter for selecting only
CLNP packets. "clnp.nlpi" should *always* be 0x81 in CLNP packets, and
should not ever be present in non-CLNP packets (if the NLPID weren't
0x81, it wouldn't be CLIP...).
> 3) Using tethereal:
> I'm trying to convert the captured traffic to a Sniffer pro 3.0.05
> (Network Associates co) format ,that would let me dissasemble and get
> upper OSI layer (transport,session,presentation,etc..)
> I execute
> tethereal -i lan0 -f clnp -F Sniffer -w myfile.out
> but :
> Sniffer is not a valid capture file type
Yes, that's correct, it's *not* a valid capture file type.
For one thing, there are (at least) three *different* capture file
formats used by Sniffers:
the format used by the classic DOS sniffers;
the format used by older versions of the Windows-based Sniffers;
the format used by newer version of the Windows-based Sniffers.
If you run "tethereal -h", it will list the valid arguments to the "-F"
flag.
(Or, if it's Ethereal 0.9.4, it'll dump core instead, due to a bug.
That bug will be fixed in the next release.)
The value for "-F" for the DOS-based Sniffer file format is "ngsniffer".
The value for "-F" for the older Windows-based Sniffers is
"ngwsniffer_1_1". ("1_1" refers the the version number in the file,
"001.100"; that's not necessarily the version number of the program.)
The value for "-F" for the newer Windows-based Sniffers is
"ngwsniffer_2_0", but that's only supported in Ethereal 0.9.4 and later.
"ngwsniffer_1_1" should be good enough, so you don't *need*
"ngwsniffer_2_0". If that doesn't work, try "ngsniffer".
Note also that Ethereal should handle both CLTP and COTP, although we
don't handle many protocols atop CLTP or COTP, so the Sniffer might be
useful for that.
> 4) the message :
> /usr/lib/dld.sl: Unresolved symbol: __udivdi3 (code) from
> /opt/ethereal/lib/ethereal/plugins/0.9.1/gryphon.sl
> is always present when I launch the ethereal /tethereal command
I don't know why that happens. (And I no longer have access to an HP-UX
system on which to do anything about it.) Somehow, the Gryphon plugin
dissector either isn't statically linked with whatever support library
does 64-bit division for code generated by whatever compiler compiled
it, or that library is a dynamic library and it's somehow not binding to
it at run time.
As long as you have no Gryphon packets, that shouldn't be a problem.
(And unless you have a Gryphon device from The Dearborn Group, to
connect their automotive diagnostic devices to a LAN:
http://www.dgtech.com/products/gryphon.phtml
you probably won't have any genuine Gryphon packets; you might, however,
be unlucky enough to have TCP traffic on port 7000, that being the port
that Gryphon uses. If that causes a problem, remove the "gryphon.sl"
file.)
