Re: pcap filter expressions and OS X

[Guy Harris <guy () alum mit edu>]

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:tcpdump-workers-request () tcpdump org?body=unsubscribe