tcpdump mailing list archives
Re: Initializing a device
From: Akos Vandra <axos88 () gmail com>
Date: Thu, 5 Jan 2012 10:40:21 +0100
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.
Current thread:
- Initializing a device Akos Vandra (Jan 04)
- Re: Initializing a device Sam Roberts (Jan 04)
- Re: Initializing a device Guy Harris (Jan 04)
- Re: Initializing a device Akos Vandra (Jan 05)
- Re: Initializing a device Guy Harris (Jan 06)
- Re: Initializing a device Akos Vandra (Jan 06)
- Re: Initializing a device Jakub Zawadzki (Jan 06)
- Re: Initializing a device Akos Vandra (Jan 06)
- Re: Initializing a device Guy Harris (Jan 11)
- Re: Initializing a device Akos Vandra (Jan 12)
- Re: Initializing a device Guy Harris (Jan 12)
- Re: Initializing a device Akos Vandra (Jan 12)
- Re: Initializing a device Akos Vandra (Jan 17)
- Re: Initializing a device Akos Vandra (Jan 05)
- Re: Initializing a device Guy Harris (Jan 06)