[Guy Harris <guy@xxxxxxxxxx>]

> Mac OS X looses the network connection
> - after I start the capture
> - only when the interface is put into promiscuous mode
> 
> This also happens with tcpdump and tcpflow so I guess you
> can't do much about it, may be the interaction of AirPort
> with libpcap...

Or with the BPF code in the kernel.  You should report that to Apple as
a bug.

> I had the same problem with Etherpeek under
> Mac OS 9.

Perhaps both the MacOS Classic and MacOS NT have a problem in their
AirPort drivers (I assume from your earlier reference to the AirPort
that the capture in question was done on a wireless interface), although
it's a little surprising that both OSes have the problem - I don't know
how much networking code they share.

> More important:
> 
> - I had to setenv CFLAGS -traditional-cpp, otherwise
>   this happens:
> 
>   cc -DHAVE_CONFIG_H -I. -I. -I.     -Wall -g -O2 -I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -c   buffer.c
>     buffer.c:1308: bad macro argument list
>   cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode

Sounds a bit like a crap compiler, given that wiretap/buffer.c has only
143 lines, so there's no line 1308 to *have* a bad macro argument list.

> - There is no pcap_version in the libpcap supplied by
>   apple.

Well, that's pretty bogus of them, given that "pcap_version" has been in
libpcap for ages; you should report that to Apple as a bug.

>   I saw that you have ifdefs for this to handle
>   Windows. Maybe another one for Darwin would be good.

Well, I'd be inclined to do it with a configure-script check, instead,
if possible, just in case Apple fixes that problem in the future.

> - the gryphon and mgcp plugins conflict, I had to
>   remove one manually from the Makefile:
> 
> 
> 
> /usr/bin/ld: multiple definitions of symbol _plugin_init
> plugins/gryphon/.libs/libgryphon.a(packet-gryphon.o) definition of _plugin_init in section (__TEXT,__text)
> plugins/mgcp/.libs/libmgcp.a(packet-mgcp.o) definition of _plugin_init in section (__TEXT,__text)
> /usr/bin/ld: multiple definitions of symbol _plugin_reg_handoff
> plugins/gryphon/.libs/libgryphon.a(packet-gryphon.o) definition of _plugin_reg_handoff in section (__TEXT,__text)
> plugins/mgcp/.libs/libmgcp.a(packet-mgcp.o) definition of _plugin_reg_handoff in section (__TEXT,__text)
> /usr/bin/ld: multiple definitions of symbol _version
> plugins/gryphon/.libs/libgryphon.a(packet-gryphon.o) definition of _version in section (__TEXT,__const)
> plugins/mgcp/.libs/libmgcp.a(packet-mgcp.o) definition of _version in section (__TEXT,__const)
> rm -f .libs/etherealS.o

Do either of them *work* after this?  They aren't, as far as I know,
linked together into one file on platforms that libtool thinks support
run-time linking, so this may be a result of libtool not handling MacOS
X; however, I don't know whether libtool's linking of them into, I
think, the main Ethereal binary results in something that the GLib
run-time linking wrapper handles.

	...

> Here is the configure output, maybe this is of interest to you...
> 
> [localhost:~/src] liyanage% tar -xzf ../Download/ethereal-0.8.17-a.tar.gz
> [localhost:~/src] liyanage% cd ethereal-0.8.17/
> [localhost:~/src/ethereal-0.8.17] liyanage% setenv CFLAGS -traditional-cpp
> [localhost:~/src/ethereal-0.8.17] liyanage% ./con
> config.guess* config.sub*   configure*    
> [localhost:~/src/ethereal-0.8.17] liyanage% ./configure
> creating cache ./config.cache
	...

> checking for dlfcn.h... no

...which means Ethereal doesn't think run-time linking is supported (it
shouldn't check for "dlfcn.h", it should check whether the GLib routine
to test for run-time linking returns "true" or "false", so that it will
handle run-time linking on HP-UX, but I suspect it'll still return
"false" for "does MacOS X support run-time linking?", even though MacOS
X, as far as I know, does - that'd require some MacOS X developer to
supply run-time linking support to the GLib maintainers).

	...

> checking dynamic linker characteristics... no
> checking if libtool supports shared libraries... no
> checking whether to build shared libraries... no
> checking whether to build static libraries... yes
> checking for objdir... .libs
> checking for dlopen in -ldl... no
> checking for dlopen... no
> checking for dld_link in -ldld... no
> checking for shl_load... no
> checking for shl_load in -ldld... no
> creating libtool

...which means libtool doesn't think MacOS X supports run-time linking.

(And both of them mean that neither plugin is likely to work.)

So we need to fix up the configure script stuff to better detect a lack
of run-time linking support.