[Carl Klatsky <cklatsky@xxxxxxx>]

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 |