Ethereal-dev: Re: [Ethereal-dev] pcap: file has %u-byte packet, bigger than maximum of %u - On
phlegay@xxxxxxx wrote:
But I needed to compile again the full ethereal without libz (./configure
–without-libz).
I infer from the Fink page that they have separate builds for different
OS X releases, so I wouldn't expect there to be any issues resulting
from any chances to libz between Jaguar and Panther to fix the libz
problem described in the very long comment in "wiretap/file_wrappers.c"
(and I don't know whether any pre-Panther releases had that problem).
I'm a bit surprised that the Fink package is having a problem.
I'm also surprised that the problem would show up on one of the machines
but not the other, given that they're running the same OS version (and
that the G5 is being run as a 32-bit machine, so it's not as if it's a
32-bit vs. 64-bit problem).
I could not compile in this context (undefined symbol in
pcap-util.c => I have to do make clean to avoid this error).
What symbol was that?
So, I go back to Mac G5
=========================
and I try to compile ethereal (via ./configure ; make). I get an error
(undefined symbol in pcap-util.c). So What does fink to do in order to compile
properly ethereal ? I ask fink commander to work into a terminal, so I see the
configure option :
./configure –prefix=/sw –mandir=/sw/sahre/man –without-net-snmp – without-adns
–disable-usr-local –without-ssl
New compilation, with this configure command. Conclusion : no compilation error,
but some link errors :
ld : undefined symbols :
_pcre_compile
_pcre_exec
_pcre_study
That's odd - it found libpcre, but didn't add -lpcre to the Makefile?
A question is How fink succeed to compile and link ? Fink says that ethereal
depends on pcre and load it, but the configure file says pcre is not used !
That's odd. What happens if you do "make distclean" before running
"configure"?
Notice on Mac G5
------------------
- libz is
What about libz on the G5?
- Mac G5, make build a tethereal (but on G4 only ethereal is build).
That's *VERY* strange - you *can* tell the configure script to generate
a Makefile that builds only Ethereal (with "--disable-tethereal"), but I
presume you didn't do that, and I don't see why Fink would do that.
Now, go back to the G4 Macintosh
================================
make clean
./configure –prefix=/sw –mandir=/sw/sahre/man –without-net-snmp – without-adns
–disable-usr-local –without-ssl—wihtout-libz
make
Unable to link : the _uncompress is not found ? Where can find it ?
Just "_uncompress"? There's no function "uncompress()" in Ethereal, or
that Ethereal uses (the leading underscore is probably a result of OS X
not being one of the UN*Xes that got rid of the old leading underscores
in C-language symbols).
==================================================
In order to debug this week-end my questions are :
==================================================
- Is the bug known ? Is it really a zlib bug ? Where can I find “right” sources
of libz ?
There have been various bugs in libz.
The first one we encountered is a problem that shows up on systems with
32-bit "long"s and 64-bit "off_t"s, such as the BSDs (including OS X);
that's the problem described in the long comment in
"wiretap/file_access.c" (which explains how we work around that problem,
so that problem shouldn't be occurring with Ethereal).
Another one, as I remember, is that there was a problem with "gzseek()"
on *uncompressed* files, which showed up in older versions of libz -
such as the one that came with X11. However, Panther, at least, doesn't
provide libz with X11 (unlike certain Linux distributions - which also
provide their *own* libz which *isn't* that older one), so that
shouldn't be a problem. In fact, I have no problem reading uncompressed
or compressed capture files on the Ethereal built from the SVN tree on
my machine, so the libz that comes with Panther seems OK.
How many "libz.dylib" files are on your G5, and how many are on your G4?
Are there ones on the G4 that aren't on the G5? If so, perhaps
Ethereal's using one of the extra ones, and perhaps it has one of the
libz problems.
- Is it possible to have no compressed captured file ?
Yes. That's the default - Ethereal doesn't write compressed capture
files. However, if built with libz, Ethereal uses libz routines to read
both compressed *and* uncompressed capture files - libz has code to
figure out whether a file is compressed or not (because it understands
the gzip file format, and the gzip magic number) and, if a file isn't
compressed, just reads the raw file data.
- Compression is for captured file ? For understanding some protocols ? Both ?
In recent versions of Ethereal, it's used for both - Ethereal can use
libz to read capture files (both compressed and uncompressed), and also
uses it to uncompress data transferred with the "gzip" or "deflate"
content encoding over HTTP and zlib-compressed packets in the SoulSeek
protocol.
Is there one compression algorithm or several ?
One - the one used by gzip, zlib, and various ZIP file programs.
- Is it possible to have a well formated captured file to check, if the read
mechanism of my ethereal is OK ?
Yes. The page at
http://wiki.ethereal.com/SampleCaptures
has a number of capture files, some of which are compressed (the ones
with names ending with ".gz") and some of which aren't.
==> Of course now, I know where ethereal reads the captured file, but have you
pointer to know where the capture files are created and written ?
I have to understand where is the bug :
Bug when writing the file ?
Bug when reading the file ?
Bug in both ?
Bug when reading the file.
