> To configure ethereal I need the following CFLAGS:
> (I'm using the (optional) ANSI-C Compiler from HP)
> export CFLAGS="-Aa -Ae +O2"
> -Aa: ANSI C
> -Ae: Extensions to ANSI (needed for 'long long')
> +O2: Optimization
>
>
> The resulting Makefile needs to be corrected:
Makefiles are automatically generated, so we'd have to somehow make the
script generated from "configure.in" ("configure" is also automatically
generated) set the C flags appropriately for various compilers, *if*
that's possible (i.e., if autoconf-generated code can figure out which
compiler is being used).
> The rule for rdps is missing the CFLAGS (thus failing to compile)
I've added it.
> I don't have a header dlfcn.h (what is this suposed to be ?)
It's the header that, on UNIXes that adopted AT&T's API for run-time
linking, declares the functions used for that.
Unfortunately, HP didn't do so, although, as that API is in the UNIX 98
spec, as I remember, they'll presumably do so eventually.
Given that we're now using the gmodule stuff (we use the libltdl library
in the 0.8.1 release, but the code in CVS uses gmodule), we don't *need*
to have the AT&T API available, so perhaps we should either always build
the plugins stuff, or use some way of figuring out whether the run-time
linking support in gmodule is real or if it's just linking stuff in
statically and faking the run-time linking (as libltdl does; I don't
know if gmodule does).
> Usage-problem:
> I want to use nettl to gather network-Info. I gather the data with:
> nettl -tn pduin pduout -e ns_ls_nfs ns_ls_udp ns_ls_tcp -file ~/TRC
> The I stop the tracing with
> nettl -traceoff -e all
>
> When I load the resulting trace-File in ethereal (File/load) nothing
> happens, except that the filename appears in the lower right corner with
> "Drops: 0".
Do you have the trace file? It may be a bug in Wiretap's handling of
nettl files, and it'd be a lot easier to debug and fix if we have a
trace file.
> I need nettl for some of our machines, because they use STREAMS not DLPI...
I.e., some network interfaces use raw STREAMS, rather than STREAMS plus
DLPI? (Note that, as I understand some stuff in the HP-UX documentation,
some HP-UX network devices - e.g., ATM interfaces - use DLPI but don't
use the standard DLPI provider, which, at least currently, may render
them unavailable to libpcap; I'd consider that a bug in libpcap.)
By the way, on those systems where you *can* capture packets with
Ethereal:
1) do you get a list of interfaces in the combo box in the
"Capture:Start" dialog box?
2) can you specify the interface by name, or do you have to do
the gross hack wherein you use "lanscan" to get the PPA of
the device, and then specify the device as "dlpiN", where "N"
is the PPA?
I have a patch to libpcap that fixes those problems on HP-UX 11.00; I
don't know whether it works on 10.20 or not.