Wireshark · Ethereal-users: Re: [Ethereal-users] using ethereal & tethereal 0.9.1 in HP-UX

["Erick B." <erickbe@xxxxxxxxx>]

Guy,

With tethereal, editcap, and mergecap version 0.9.4 on
Win32 the -F option ngwsniffer_2_0 is not a valid
type. Ethereal works fine, but not the CLI based
programs.

Error from all 3 is:

"ngwsniffer_2_0" is not a valid capture file type

Just thought I'd let you know... 0.9.4 is a big
improvement for Win32 in my opinion. Kudos to Novell
for the NCP dissector - helped me today!

Also, thanks for the info below on the sniffer version
strings.

Erick

--- Guy Harris <guy@xxxxxxxxxx> wrote:
> 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.)
> 
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
>
http://www.ethereal.com/mailman/listinfo/ethereal-users


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com