tcpdump mailing list archives
Re: supporting extend 'open live capture' parametes
From: Guy Harris <guy () alum mit edu>
Date: Mon, 11 Feb 2008 01:20:27 -0800
Paolo Abeni wrote:
Perhaps I'm missing the point, but I think a similar situation currently happens in the pcap_findalldevs() function, which ultimately calls pcap_open_live()/pcap_close() for each discovered device.
That's an implementation detail; if there were a way of determining whether it's possible to capture on a device without trying to open it, that's what pcap_findalldevs() would use.
We can implement the pcap_is_monitor_mode_available(char* device_name) API [perhaps with a shorter name :-) ] in a similar fashion; something like: handle = pcap_create() pcap_set_device(handle, device_name); pcap_activate(handle); ret = pcap_get_monitor_mode_availability(handle); pcap_close(handle) return ret; This is quite time inefficient, but I think that this way the implementation of the various pcap_get_property() api is very easy. Moreover, I hope/think that they don't have any time constraint. What do you think ?
What's the advantage of requiring that pcap_get_monitor_mode_availability() be called after pcap_activate()?
It means you don't have to specify a device name in pcap_create(), but I suspect the majority of pcap_create() calls will be followed by a pcap_set_device() call, and
handle = pcap_create(device); is a little less code that handle = pcap_create(); pcap_set_device(handle, device);In addition, if you specify a device name to pcap_create(), it means that, for example, we could conceivably have the handle returned by pcap_create() point to a structure that begins with a pcap_t and has device-dependent information at the end - this would mean that the pcap_t structure wouldn't have to include all possible forms of device-dependent information; the device-dependent information could, in most if not all cases, be defined in the pcap-XXX.c routine.
That trick does have the disadvantage that you have to do some casting to convert the pcap_t * passed to various routines into a pointer to the appropriate platform-dependent structure, and I didn't see anything obvious in the C89 spec to say that if you know that a pointer to a
struct foo { int a; char *b; char c[12]; }; really points to a struct bar { struct foo f; int a2; char b2[4]; char *c2; };you can cast that "struct foo *" to a "struct bar *" (although it might be implied by other stuff in the spec).
Having pcap_create() take a device argument might also be inferred as indicating that pcap_create() will check the validity of the device argument, which I wouldn't expect to be the case - but, then again, having pcap_set_device() take a device argument could be inferred as indicating that pcap_set_device() will check the validity of the device argument, which isn't the case.
Having pcap_get_monitor_mode_availability() be usable only after pcap_activate() might be inferred as indicating that pcap_set_monitor_mode() be usable after pcap_activate() - which I don't expect to be the case on all platforms (for example, on Mac OS X 10.4, pcap_set_monitor_mode() will affect the device to whichpcap_activate() binds the BPF device, i.e.:
if you're opening device enN, and there exists a wltN device, pcap_activate() will bind to that device rather than to the enN device;
otherwise, monitor mode isn't available on the device, and pcap_activate() will fail).
A call to pcap_set_monitor_mode() could be supported after opening on most other platforms, and it *could* support it on OS X 10.4 by closing the BPF device, re-opening it, performing all the other operations on it, and binding it to the new appropriate device, but that'd be a significant mount of work to support something that's probably not needed in practice.
- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Current thread:
- Re: supporting extend 'open live capture' parametes Abeni Paolo (Jan 14)
- Re: supporting extend 'open live capture' parametes Michael Richardson (Jan 14)
- <Possible follow-ups>
- supporting extend 'open live capture' parametes Abeni Paolo (Jan 21)
- Re: supporting extend 'open live capture' parametes Guy Harris (Feb 05)
- Re: supporting extend 'open live capture' parametes Guy Harris (Feb 05)
- Re: supporting extend 'open live capture' parametes Abeni Paolo (Feb 07)
- Re: supporting extend 'open live capture' parametes Guy Harris (Feb 07)
- Re: supporting extend 'open live capture' parametes Guy Harris (Feb 05)
- Re: supporting extend 'open live capture' parametes Paolo Abeni (Feb 11)
- Re: supporting extend 'open live capture' parametes Guy Harris (Feb 11)
- Re: supporting extend 'open live capture' Paolo Abeni (Feb 11)
- Re: supporting extend 'open live capture' Guy Harris (Feb 11)
- Re: supporting extend 'open live capture' parametes Guy Harris (Feb 11)