Re: supporting extend 'open live capture' parametes

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

Abeni Paolo wrote:

> I assume that the my initial suggestion is going to be dismissed, right ?!?

The extensible live-capture-open would be better (for one thing, a 
global variable would have problems with multiple threads), but it might 
be nice to get *something* into 1.0, so if we can't get the extensible 
live-capture-open in, the global variable might go in.

> I think that a complete solution can be pretty complicated; such
> information could be provided with a buffer filled with TLV items, much
> like the 'extened open live capture' call. Supported values for each
> parameter could be inserted in the corresponding 'value' part of each
> item, putting all the supported values in the same item.

Would the caller put in "empty" TLV items, which would be filled in by 
the "get capabilities" routine?  That'd require the caller to know the 
maximum number of supported values; that might work for now with, for 
example, 802.11 channels, but if a future 802.11xyzzy standard supports 
30 channels....

Or would the routine supply all the capabilities supported by the device?

> A possible API could be:
>
> int pcap_get_capabilities(const char* device_name, char* optbuf,
>         unsigned size); /* fill optbuf up to size bytes with TLVs and returns
>                            error code or the number of bytes used */
>
> There is an issue: optbuf can be not large enough to handle all
> supported parameters/values; we can enforce a reasonable upper bound for
> the TLVs buffer or we can use a TLV entry to specify the required buffer
> len.

...or have the application to keep trying with bigger buffers if the 
first buffer isn't big enough.

Another possiblity would be

        int pcap_get_capabilities(const char *device_name, char **caps);
        void pcap_free_capabilities(char *caps);

where the first one allocates a table of capabilities and supplies it, 
and the second one frees an allocated table.

> To completed the picture, in extended open live capture the timeout
> parameter could be provided via the TLV buffer, since is not supported
> by all platform:
>
> int pcap_open_live_ex(const char *device, int snaplen, int promisc,
>         const char * optbuf, char *errbuf);

It'd have to return a pcap_t * in some fashion.

Well, as long as we're adding a new API, I'd:

        replace "promisc" with "flags", as per WinPcap's pcap_open():

                http://www.winpcap.org/docs/docs_41b2/html/group__remote__open__flags.html

	have "device_name" either be a device string or a URL for a remote 
capture device, again as per pcap_open():

	 
http://www.winpcap.org/docs/docs_41b2/html/group__wpcapfunc.html#g2b64c7b6490090d1d37088794f1f1791

        possibly allow a filter to be supplied at open time.

Allowing a filter to be supplied at open time could be done by:

	1) supplying a filter expression, compiled at install time (so you'd 
have to supply an optimizer flag and netmask);

	2) splitting the filter compilation into a parser and a code generator, 
and supplying an expression tree from the first part (you'd still have 
to supply an optimizer flag, but the expression tree could possible have 
the netmask folded in) - splitting the compilation might make it easier 
to change the way operators such as "vlan" work, so that "(vlan and X) 
or Y could have "vlan" apply only to X, not Y, but whether that'd be an 
improvement is another matter, and it might also let programs use 
different filter syntaxes, e.g. reducing the confusion in Wireshark 
between capture and display filters, but I have reasons for wanting to 
support at least some of the libpcap syntax in *display* filters (e.g., 
"host foo", so that people who want to *exclude* host foo from the 
display do "not host foo" rather than "ip.addr != foo", which doesn't do 
what they think it does);

	3) supply a BPF program, which requires that you get the DLT_ value 
before opening - which might not be too hard to do;

	4) supply a new data structure that could include a BPF program or some 
other filter type - this, like 1) and 2), could let us try to do 
CMU/Stanford packet filtering in the kernel in, say, Solaris.

Also, I think Gianluca Varenni suggested returning error codes rather 
than error strings, for the benefit of, for example, applications that 
want to know *why* a call failed rather than just knowing that it failed 
and having a string to show the user.  We could either have it return an 
"int", with 0 being success and non-0 being an error code, and take a 
"pcap_t **" argument and supply the "pcap_t *" through that argument, or 
return a "pcap_t *", with non-null being success and null being failure, 
and take an "int *" argument and, on failure, supply the error code 
through that argument.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.