Ethereal-users: Re: [ethereal-users] Re: An updated version of the changes to fix "typeof netwo
Here's the latest on my follow up with tcpdump. Firstly, it seems that
my original tcpdump core dump problem was local only to my target
machine. I could load the tcpdump binary and run it OK from the SuSE
6.3 CD on other, non-ATM based machines. Now, when I loaded the source
of both tcpdump and libpcap from the SuSE CD and built them on my target
machine, it worked without core dumping, but I could not see ATM
interfaces. But, from my earlier tests with Ethereal (before the latest
changes) I recalled times when I could see an atm interface in the
capture pull down, and sometimes on certain builds I couldn't.
So, I figured out that when I installed the libpcap.a from the SuSE CD,
instead of the source, that's when I could see atm interfaces. The
files installed as part of the libpcap.a package are:
/usr/include/net/bpf.h
/usr/inlucde/pcap-nameb.h
/usr/include/pcap.h
/usr/lib/libpcap.a
The problem was that when I installed the same version (0.4a6) but using
the source package from the SuSE 6.3 CD, the bpf.h under
../libpcap-0.4a6/bpf/net was different and DID NOT have DLT type 0x18.
Which explained neatly why the pre-changed Ethereal and tcpdump both
could not see atm interfaces. The recent changes posted fixed
Ethereal. What I did for tcpdump was to clear out any libpcap.a I had.
Then I re-installed the libpcap.a package (non-source) with the "good"
bpf.h, then installed source for tcpdump 3.5 in /opt. Built that and it
included the "good" libpcap.a. In the end I got:
#tcpdump --version
tcpdump 3.5
libpcap 0.4a6
With that combo, I can now tcpdump -i atm0 and capture traffic.
The upshot is I know have both Ethereal and tcpdump capturing from ATM.
I'll report a bug/issue with the way the packaged the libpcap binary vs.
source.
Thanks to all for the help.
Carl
P.S I sense some cold barley and hops based beverages in my near
future...
Guy Harris wrote:
>
> > YESSS!!! I rebuilt Ethereal with the versions of libpcap.c and
> > capture.c that were included in the original message below. This worked
> > fine.
>
> Spiffy. It worked for Christian as well, so I'll be checking it in
> (along with configure-script stuff to check whether the machine *has*
> <pcap.h>, so as not to include it if it's not there).
>
> > I now have a better understanding of the libpcap role. My current
> > tcpdump, which works on my target machine, was built from source
>
> Which source? The source that came from the SuSE CD, or some other
> source?
>
> > BUT
> > uses the libpcap.a that came off of my SuSE CD. If I try to build
> > libpcap from the sources on my CD, then build tcpdump from that libpcap,
> > the resultant tcpdump doesn't work right.
>
> I.e., the resulting tcpdump works differently with the libpcap binary
> that came from SuSE and the libpcap library built from the source that
> came from SuSE?
>
> I'd call that a bug in SuSE 6.3, if the source that comes with it
> doesn't produce the binary that comes with it. Complain to SuSE about
> that.
>
> Does the binary tcpdump that comes with SuSE 6.3 work, or is that the
> one that was dumping core? If it doesn't work, that's another bug to
> report to SuSE.
>
> > My next question is, can I build libpcap from source using the libpcap.c
> > you sent?
>
> No. "libpcap.c" is part of Ethereal's Wiretap library for reading
> capture files; it handles reading capture files generated by libpcap.
> It's not a part of libpcap itself. (Ethereal uses Wiretap to read
> capture files, as it can handle non-libpcap capture files; it uses
> libpcap to capture packets, however.)
>
> > If I can, then I think the changes you made will propagate
> > into my tcpdump, and I should then be able to capture from an atm
> > interface using tcpdump. When I look in the source for my libpcap, I
> > only see a libpcap.a, not libpcap.c. How/where does that archive get
> > built?
>
> It gets built from the *other* source files; "foo.a" doesn't necessarily
> get built from "foo.c" - "foo.c" turns into "foo.o", but "foo.a" could
> well contain "bar.o" and "bletch.o" but not "foo.o".
--
|Carl Klatsky |Ph: 732.530.4471 |
|3NO Systems, Inc. |Fax: 732.530.2110 |
|http://www.3no.com |E-mail: cklatsky@xxxxxxx |
