[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] supporting extend 'open live capture' parametes
From:       Guy Harris <guy () alum ! mit ! edu>
Date:       2008-02-11 9:20:27
Message-ID: 47B0135B.7000503 () alum ! mit ! edu
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]