Re: Initializing a device

[Akos Vandra <axos88 () gmail com>]

Hi!

I browsed through the code of pcap_open_live, and pcap_set_promisc,
and related stuff, and I think that now I understand how this works.

However in my opinion, the way parameter passing is implemented breaks
the principle of modularity.

iface here = pcap_canusb, pcap_usbmon, etc.
What is the correct term for these? I keep using iface and module
interleavedly in my mails...

If - let's say - my interface (canusb) needs a parameter for the baud
rate, and another interface, let's say a more low-level radio iface
needs parameters like frequency, channel, modulation (ASK or FSK),
then to fully support these capture ifaces, we would need to add a lot
of parameters to pcap_open_live, and a lot of API functions (like
pcap_set_modulation, pcap_set_channel) which are used by a single
iface.

That is - in my opinion - bad.

My suggestion for a solutoin - which is a *lot* of work -, but will
add a nice functionality to libpcap:

Please view this from a higher level, if you guys like it we might
think about data structures, etc later, I have ideas about that too,
but they are quite immature yet.

Add a new _op command list_parameters, which returns a list of the
parameters that it needs with data about: parameter name, type,
default value. If the _op is unset, or returns null, it means the
iface doesn't need any (backw compatibility).

Add a few new API calls to create a list of parameters, and set values
in it. These functions check if the correct type of argument is given.
params_create - returns a handle
params_set_uint8 - sets an uint value, etc.

Then pass this parameters structure to the activate_op, and it can do
the activation based on these parameters.

Now if we add a new parameter, there is no need for new API calls,
just add a new entry to the param_list.

This would be very handy for UIs too, as they could implement a
generic capture interface options dialog, and use the list returned by
the param_list_op to populate it with widgets or controls.

I think the whole decision has one very sensitive part: As this
architecture mainly eases implementation of different kinds of ifaces
which are *not* based on ethernet, like my can device, or an i2c
device, or a generic radio device, or whatever comes to mind, the main
question is if it's libpcap's goal to support these.

I think why not have one very cool capture library that can be used
for as many interfaces as possible, but you guys decide! :)

Regards,
  Ákos Vandra

On 5 January 2012 01:36, Guy Harris <guy () alum mit edu> wrote:
> On Jan 4, 2012, at 4:10 PM, Akos Vandra wrote:
>
> > When opening a capture device, is it possible to hand off some
> > initialization data to the libpcap handler?
>
> Yes.
>
> The ways to do that would either be to
>
>        1) have the device name include parameters such as that
>
> or
>
>        2) add new APIs to be called between pcap_create() and pcap_activate() to set the parameters.
>
> We currently do not use 1) for any devices; 2) is used not only for parameters that apply to most if not all devices 
> but also to parameters that apply to, for example, 802.11 devices (monitor mode).
>
> The former would have the advantage that using those capabilities would not require any UI changes to tcpdump or 
> Wireshark or....
>
> The latter would have the advantage that, at least for a GUI, you could provide a possibly-more-convenient UI, e.g. 
> in Wireshark's Capture->Options dialog.  Whether a command-line argument to tcpdump/TShark/dumpcap/etc. would be more 
> pleasant to use than adding ",baudrate=XXXX" to the end of the device name is another matter.
>
> > For example, I have just added a handler for a canusb device. When
> > opening the device, it would be nice if it was possible to set the
> > baud rate, etc.
> > Would it be possible to use the BPF filter for this?
>
> No.
>
> The filter is simply a way to discard packets deemed as "uninteresting", and possibly to do so at a low-enough level 
> to keep them from using up CPU time to copy them, buffer resources in the capture mechanism, etc..
>
> > (btw, I don't
> > really understand what BPF filters are, where can I get some
> > documentation on this?)
>
> You might look at
>
>        http://www.tcpdump.org/papers/bpf-usenix93.pdf
>
> and at the pcap and pcap-filter man page, and maybe
>
>        http://sharkfest.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest'11_Keynote_Address.pdf
>
> as well.
>
> > is the inject_op operation for sending data through the device?
>
> Yes.  It's what implements pcap_inject() and pcap_sendpacket().  (The two routines exist because WinPcap added one of 
> those routines and OpenBSD's libpcap added another, with different names and slightly different return values, and we 
> wanted to allow software written for either of those APIs to work with standard libpcap.)-
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.