Re: supporting extend 'open live capture'

[Paolo Abeni <paolo.abeni () gmail com>]

hello,

On Mon, 2008-02-11 at 01:20 -0800, Guy Harris wrote:
> What's the advantage of requiring that 
> pcap_get_monitor_mode_availability() be called after pcap_activate()?

This way all the platform/device dependent code can be placed into
pcap_activate(), elsewhere we have to split/duplicated some of it in
pcap_activate() and pcap_create() [or
pcap_get_monitor_mode_availability()].

> 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);

Ok. I agree that adding a device name to the pcap_create() parameters
should be better.

> 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.

I suppose that this can be achieved also adding a 'private' field
(perhaps a pointer) in the pcap_t structure, which should be
managed/used by the platform dependent code.

> 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).

Currently this sort of trick is used by at least the gtk library, but I
don't know if they explicitly require a compiler complying with more
recent standards.

> 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.

This could be handled by a detailed api description [basically all
pcap_set_xxxx call must be performed before pcap_activate()] and by
having the pcap_set_xxxx calls returning a describing error
number/message upon wrong usage.

BTW I apologize for the very inappropriate banner appended to my
previous messages. Since I have no control over it (it was added by the
smtp server), I had to move to another mail account...

cheer,

Paolo 

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.