Re: Libpcap

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

On Jul 16, 2009, at 3:13 AM, Chris Davies wrote:

> I have a program that uses libpcap to snoop on packets for the  
> purposes of
> monitoring.
>
> It works very well when compiled on a 32 bit Linux machine and run  
> on a 32
> bit Linux and when 64 bit Linux machine and run on a 64 bit Linux.
>
> However it does not work correctly if I run the 32bit binary on a 64  
> bit
> Linux box.

What does it do other than working correctly?  "XXX does not work  
correctly" is not a good problem report, as "does not work correctly"  
could vary between "occasionally drops packets" through "doesn't show  
me any packets" all the way to "erases my entire hard disk and  
attempts to crash every network server it can find".  "Doesn't show me  
any packets", for example, would be easier to fix, as we can then  
start to try to figure out what might be happening.

> A simplified segment of my start code is
>
>    pcap_t* handle = pcap_open_live(dev, BUFSIZ, 1, 1000, errbuf);
>
>    pcap_set_buffer_size(handle,bufSize);

pcap_set_buffer_size() shouldn't be used with pcap_open_live(), it  
should be used with pcap_create() and pcap_activate() - use it between  
the pcap_create() call and the pcap_activate() call.

In fact, it will *fail* if you call it after pcap_open_live(); unless  
you've *really* simplified that segment of your start code, you're not  
checking for errors.  You should check for errors from libpcap  
routines in your code.

That's probably not the problem, however.

I *suspect* the problem could be that the code that implements memory- 
mapped capturing doesn't work correctly if the code is 32-bit but is  
running on a 64-bit kernel.  A purely system-call-based interface can  
be usually made to work with a 32-bit userland and a 64-bit kernel -  
or a 64-bit userland and a 32-bit kernel (cf. Mac OS X Tiger and  
later) - purely with kernel work (translating the arguments and  
results appropriately when copying them in and out, depending on  
whether the {kernel,userland} are 32-bit or 64-bit.  However, if you  
share a data structure between the kernel and userland, as you do with  
memory-mapped captures, that could require some work in userland - as  
well as some more design work in the kernel to ensure that it's  
*possible* for userland to make that work.

In fact, *if* the kernel only offers "version 1" of the memory-mapped  
interface, there is a 32-bit vs. 64-bit issue; the "tp_status" member  
of a "struct tpacket_hdr" is an "unsigned long", which means that,  
with a 64-bit kernel and 32-bit userland, the structure looks  
different in the kernel and in userland.  "Version 2" uses __uN types  
for all members, so that the lengths are explicitly specified as  
having a certain number of bits, so that they'll be the same in the  
kernel and in userland.

Fixing this would require a way to ask the kernel whether it's 32-bit  
or 64-bit.  (Asking the kernel what instruction set architecture it's  
using would *probably* work, although it'd require a table of which  
architectures are 32-bit and which are 64-bit - hopefully it  
distinguishes between 32-bit and 64-bit versions of particular  
architectures, including x86, MIPS, PA-RISC, PowerPC, and System/ 
3x0.)  Note that a mechanism determining what architecture is being  
used in the application in userland doesn't help.  That mechanism  
would have to be present in all versions of the kernel that support  
memory-mapped capture.

> Is there anything special I should be doing to get it to work on 64  
> bit
> platforms

Running on a system with a kernel that supports "version 2" of the  
memory-mapped interface.  I don't know what kernel version introduced  
that, but, at least from the kernel sources I have, it wasn't in  
2.6.26.5 but was in 2.6.27.9, so it presumably appeared in either  
2.6.27.6, 2.6.27.7, 2.6.27.8, or 2.6.27.9.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.