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.
