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

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Gonzalo Joaquin Araluce Goyoaga <gonzalo_joaquin.araluce_goyoaga@xxxxxxxxxx>
Date: Fri, 24 May 2002 10:18:19 +0200
Hello Guy:
I can tell you that, since I start working on telecom (1982) ,and I
belong to an R&D department, ,I have never received a such explicit
,clear , and brief answer to my set of problems. And now I report you,
the summary of the results, I got after processing your indication.

> If I just put clnp ,it works, but ,amazing thing ,just the incoming
> traffic .
There is a patch named PHNE_20892, but there is also a workaround
explained in readme.hpux:
     root>adb -w /stand/vmunix /dev/mem <return>
     lanc_outbound_promisc_flag/W 1 <return>
Tested OK.

- F ngwsniffer_1_1 option:
Tested OK

- About captured filter string :
Learning/Reading  tcpdump man pages. I will try to filter Source NSAP,
Destination NSAP.

Thanks a lot for your help.

Guy Harris 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.)

-- 
---------------------------------------------------------------------- 
| Gonzalo Araluce Goyoaga | Address: Avda Princesa Juana De Austria  |
|                         |          Km 8,700  MADRID 28021          | 
|                         | Phone  : +34 - 91 330 8359               | 
| ALCATEL SPAIN           | Fax    : +34 - 91 330 8393               | 
| VND Division            | Alcanet: 2414- 8359                      | 
| Network Management      | Email  : mailto:garaluce@xxxxxxxxxx      | 
----------------------------------------------------------------------