On Wed, May 01, 2002 at 05:27:59AM +0200, Brad Knowles wrote:
> I tried adding "-H" to the compilation of the iflist.c file that
> you sent me, and cpp barfs with "cpp-precomp: Invalid option '-H'".
> I'm not sure how to turn off cpp, so that the argument gets passed
> through.
Oh, well, I guess that's another Apple improvement.
> > Then check what underlying C type "uint32_t", as it appears in xprobe,
> > is, and see if it's the same type as whatever type "bpf_u_int32" is
> > defined to be in the header file it uses.
>
> Hmm. Okay, I'm guessing that this is the problem:
>
> % grep -i uint32_t xprobe/xprobe-0.0.2/*.h
> xprobe/xprobe-0.0.2/config.h:#define uint32_t unsigned long
>
> % grep -i bpf_u_int32 libpcap/libpcap-0.7.1/p*.h | grep typedef
> libpcap/libpcap-0.7.1/pcap.h:typedef u_int bpf_u_int32;
Yup. The fact that
#define uint32_t unsigned long
shows up in a "config.h" line conveys some hope, i.e. that may mean that
the configuration script decided that on your machine "unsigned long" is
a 32-bit unsigned integer, rather than some programmer deciding that
it's a 32-bit unsigned integer on all platforms (which it isn't - it's a
64-bit unsigned integer on many platforms).
> > to be somewhat bogus code anyway; why do "interf.net" and
> > "interf.netmask" not have type "bpf_u_int32", so that pointers to them
> > already have the right type? If they aren't 32-bit unsigned integers,
> > then the code *should* do
>
> Remember that they are linking to an older version of libpcap --
> maybe this is the way things are done in the older library?
No, it's the same in all versions of libpcap.
> Or maybe it just happens to work by accident with the older library on
> their OS?
That particular bit of casting should work on any 32-bit platform. The
problems you're seeing are probably not the result of that.
> > and if they *are* 32-bit unsigned integers, they should be declared as
> > such by making them "bpf_u_int32" (or the cast should be to
> > "bpf_u_int32", not to "uint32_t", but that runs the risk that they might
> > have their type changed to a value of a different size or type, which
> > would cause the code not to work, but the cast would squelch compiler
> > complaints).
>
> Doing a global search-and-replace is something I could do, but I
> would have serious reservations as to whether or not the result would
> compile -- or blow up my machine. ;-)
>
> > Well, that's bizarre. I guess that's either some flavor of
> > "improvement" in the standard libpcap in MacOS X, or a kernel
> > "improvement" that makes SIOCGIFCONF not work, so that
> > "pcap_lookupnet()" can't manage to find any devices.
>
> I'm pretty sure that the system-supplied version of libpcap.a got
> over-written when I tried to build and install libpcap-0.7.1.
I doubt that's the case - the system libpcap is probably installed
either in "/usr/lib" or in some other system directory, not in
"/usr/local/lib".
What does
ls /usr/lib/libpcap*
print?
> > libpcap 0.7.1 *always* has "pcap_findalldevs()", regardless of whether
> > "HAVE_IFADDRS_H" is defined. It just has different *implementations* of
> > it, depending on whether it's defined or not; there are two different
> > implementations in "inet.c", one of which is used if it's defined, and
> > one of which is used if it's not defined.
>
> Is there a way we could make sure which version is getting
> defined and included in the library?
Well, you could put the line
#error "getifaddrs version"
after the #ifdef in
#ifdef HAVE_IFADDRS_H
int
pcap_findalldevs(pcap_if_t **alldevsp, char *errbuf)
{
i.e.:
#ifdef HAVE_IFADDRS_H
#error "getifaddrs version"
int
pcap_findalldevs(pcap_if_t **alldevsp, char *errbuf)
{
and put the line
#error "nongetifaddrs version"
before the other version, i.e.
#endif /* HAVE_PROC_NET_DEV */
#error "nongetifaddrs version"
int
pcap_findalldevs(pcap_if_t **alldevsp, char *errbuf)
{
and then try compiling libpcap. If you get a "getifaddrs version" error,
you're getting the first version; if you get a "nongetifaddrs version"
error, you're getting the second version; if you get neither error, it's
somehow not compiling it in at all (but that's unlikely, as there's just
a
#ifdef
...
#else
...
#endif
in there, and *one* of them has to be compiled in).
Then, obviously, remove those lines.
However, don't do that yet, as it's not necessarily the case that
"pcap_findalldevs()" isn't in the 0.7.1 libpcap - keep reading.
> > It appears that libpcap 0.7.1 isn't in "/usr/local/lib" or "/usr/lib" or
> > whatever directories "cc" searches; you're linking with some *other*
> > version of libpcap, as it lacks "pcap_findalldevs()".
>
> No, libpcap is installed in /usr/local/lib, and it's the 0.7.1
> version. There is no other file "libpcap.a" anywhere on the /usr
> filesystem:
That doesn't mean that there is no other libpcap library on your system;
try doing
find /usr -name 'libpcap.*' -ls
instead. You might find another one in "/usr/lib", with a name other
than "libpcap.a"; that'd be a shared library, rather than a non-shared
("archive") library such as "libpcap.a".
> When I compile the iflist.c you sent me with -lpcap, I only get
> the one error:
>
> % gcc iflist.c -o iflist -lpcap
> /usr/bin/ld: Undefined symbols:
> _pcap_findalldevs
What if you compile it with
gcc -I/usr/local/include -L/usr/local/lib -o iflist -lpcap
I suspect it won't get an error, and I suspect that the problem is that
when you did
% gcc iflist.c -o iflist -lpcap
it used the header file from the *system* version of libpcap
("/usr/include/pcap.h", probably, unless Apple put the system include
files somewhere other than "/usr/include") and the *system* version of
libpcap (probably a shared library in "/usr/lib", unless Apple puts
system shared libraries somewhere other than "/usr/lib").
> So, it seems to me that there is somehow a version of libpcap.a
> being built that includes the pcap_lookupdev() and pcap_lookupnet()
> routines, but not pcap_findalldevs().
Well, there's a version of libpcap - which may not be called "libpcap.a"
- somewhere on your system, which includes "pcap_lookupdev()" and
"pcap_lookupnet()", but not "pcap_findalldevs()".
It's probably the one that comes with the OS.
If so, that's probably the one the tcpdump that comes with the OS is
using, in which case the problem you're having is probably a problem
with Apple's libpcap.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
