Re: supporting extend 'open live capture' parametes

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

On Jan 13, 2008, at 3:33 PM, Michael Richardson wrote:

>  I.e. we should instead have a new pcap_open() call, and then we  
> should
> have a serious of calls that set various options or ask for various
> things based upon that handle.
>  Thus:
>
> pcap_t pcap_open_live(char *device, int snaplen, int promisc, int  
> to_me,
>                       char *ebuf)
> {
>         pcap_t pt = pcap_create();
>
>         pcap_set_mechanism(pt, PCAP_BPF);

The mechanism is platform-dependent and device-dependent; you can't  
select BPF on a platform other than the BSDs, OS X, and AIX, for  
example.

I guess if a given device offers more than one mechanism, you could  
select mechanisms from a platform-dependent list, but are there cases  
where you'd want to select a mechanism?

>         pcap_set_device(pt, device);
>         pcap_set_snaplen(pt, snaplen);
>         pcap_set_promisc(pt, promisc)
>         pcap_set_tome(pt, to_me);
>         pcap_set_errbuf(pt, ebuf);
>         if(pcap_activate(pt)) {
>                 return pt;
>         } else {
>                 return NULL;
>         }

Is the implication that the items you set don't necessarily take  
effect until pcap_activate(), so that, for example, you could, on a  
system with BPF, set the device before setting the capture buffer  
size, as pcap_activate() would first set the buffer size and then bind  
to the device?

> That would also remove the pcap_open_live() call from all the pcap-*.c
> and make the interface to a lower-level kernel driver more hidden than
> it is now.

So would all the pcap_set_XXX routines just set values in the pcap_t  
structure (and thus be mechanism-independent), with pcap_activate()  
calling through a function pointer in the pcap_t structure?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.