On Sun, Jul 06, 2003 at 06:26:04PM +1000, Joel Eames wrote:
> I'm having a problem running one of the simple example programs
> outlined in the pcap tutorial at http://www.tcpdump.org/pcap.htm. Here
> is my code:
> #include <pcap.h>
> #include <stdio.h>
>
> int main()
> {
> char *dev, errbuf[PCAP_ERRBUF_SIZE];
> pcap_t *handle;
> struct bpf_program filter;
> char filter_app[] = "port 23";
> bpf_u_int32 mask;
> bpf_u_int32 net;
> struct pcap_pkthdr header;
> const u_char *packet;
> dev = pcap_lookupdev(errbuf);
> pcap_lookupnet(dev, &net, &mask, errbuf);
Well, the first error I see in the tutorial program is that it's not
bothering to check whether "dev" is null or not. It should do
dev = pcap_lookupdev(errbuf);
if (dev == NULL) {
fprintf(stderr, "Can't find default capture device: %s\n",
errbuf);
return 2;
}
> handle = pcap_open_live(dev, BUFSIZ, 1, 0, errbuf);
> pcap_compile(handle, &filter, filter_app, 0, net);
Another error - it should do
handle = pcap_open_live(dev, BUFSIZ, 1, 0, errbuf);
if (handle == NULL) {
fprintf(stderr, "Can't open capture device %s: %s\n",
dev, errbuf);
return 2;
}
> Whenever I execute it, it gives a bus error straight after it's
> identified the network device. I ran it through gdb which gives the
> following output:
> [Switching to process 885 thread 0xb03]
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries ... done
> Trying en0
> Using en0
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> pcap_snapshot (p=0x0)
"p=0x0"? Sounds like somebody passed a null pointer to
"pcap_snapshot()"; that's used in the libpcap code generator, so the
null pointer was probably passed to "pcap_compile()".
I.e., "pcap_open_live()" probably failed and returned a null pointer.
Had the example program checked for that, it would have reported an
error.
The error is probably that you aren't running this as root *and* you
haven't made the "/dev/bpf*" devices readable by yourself; to quote the
current CVS version of the tcpdump man page:
Under BSD (this includes Mac OS X):
You must have read access to /dev/bpf*. On BSDs
with a devfs (this includes Mac OS X), this might
involve more than just having somebody with super-
user access setting the ownership or permissions on
the BPF devices - it might involve configuring
devfs to set the ownership or permissions every
time the system is booted, if the system even sup-
ports that; if it doesn't support that, you might
have to find some other way to make that happen at
boot time.
> I also commented out all of the code after the declarations and
> proceeded to uncomment each line one by one. The bus error reappeared
> when I uncommented the line "pcap_compile(handle, &filter, filter_app,
> 0, net);", which to me suggests that pcap is having a problem compiling
> the filter expression.
Yes - but it'd have a problem compiling *any* filter expression if the
"pcap_open_live()" call failed, in that program.
> In the tutorial I noted a particular comment:
> "It has been my experience that this filter does not work across all
> operating systems.� In my test environment, I found that OpenBSD 2.9
> with a default kernel does support this type of filter, but FreeBSD 4.3
> with a default kernel does not.� Your mileage may vary."
I suspect the author of the tutorial misinterpreted what he saw. "port
23" is a pretty simple filter, and I'd be surprised if it failed,
uniformly, on *any* platform. It might not work well with link layers
that have variable-length headers (Token Ring and 802.11, for example),
but that's not unique to "port 23" - any filter that looks at the IP or
TCP/UDP headers could have a problem with variable-length link-layer
headers.
> If this is the case then what should I be using for the filter
> expression? If not, then I am at a loss as to what could be causing
> this error.
What's causing the error, as noted, is probably that you're running as
yourself rather than as root *and* that you don't have access to the
"/dev/bpf*" devices - and that the program wasn't checking for the
failure of "pcap_open_live()".
None of this is, BTW, specific to Mac OS X or to any particular version
of Mac OS X. You'd probably see similar problems on Linux (a platform
on which working around the "have to be root" issue is harder - to quote
the current CVS version of the tcpdump man page:
Under Linux:
You must be root or tcpdump must be installed
setuid to root (unless your distribution has a ker-
nel that supports capability bits such as
CAP_NET_RAW and code to allow those capability bits
to be given to particular accounts and to cause
those bits to be set on a user's initial processes
when they log in, in which case you must have
CAP_NET_RAW in order to capture and CAP_NET_ADMIN
to enumerate network devices with, for example, the
-D flag).
) and on many other OSes.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
