[tcpdump-workers] How to add support for new capture interface

[Akos Vandra]

Hi all!

I have just written a trace port analyzer for ARMv7-M architecture
microcontrollers. The trace datastream is sent over a serial port to
the PC, where it is packed into frames and decoded.
I'd like to present these data packets to the user using wireshark, as
it already has a very nice and easy-to-use implementation of
presenting packet data, and filtering them.

On the wireshark list I was informed that it is using libpcap for
capturing packet data, and in order to support my trace source I
should extend libpcap.

I would like to ask for your help to get started, how can I add a new
interface to libpcap?. The hardware uses an FT2232 chip to capture the
serial data and forward it to the PC over a USB connection. The FT2232
chip implements CDC, so it can be handled as a serial port as well. At
this moment the libftdi and libusb user-space drivers are used to read
data from the chip.

Regards and thanks in advance,
  Ákos Vandra
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

[tcpdump-workers] New datasource implementation

[Akos Vandra]

Hi!

I have just written support for one of my CAN->USB adapter gadgets, so
that it would work with libpcap and thus with wireshark. I would love
to see support for my device as an option in future releases.

This is a USB adapter, and I am using libusb-1.0 to communicate with
the device. So in order for it to work, I need to libusb-1.0 linked as
well.

At the moment I am using a script-generated code to load the library
run-time, and load all the symbols to the according function pointers.
I am not very familiar with how dynamic libraries are linked, and
didn't want to hack around the makefiles too much.

So my questions are:
  - What are the steps needed to 'nicely' add support to a new device?
What do I have to add to the configuration, makefiles, #ifdefs, to add
conditional building?
  - How can I commit my newly supported device to the libpcap tree?
  - How can this libusb dependency be solved? I don't think it would
be fair to require all libpcap users to need libusb, just for one
device that they might not even use - conditional building might solve
this though.

Regards,
  Ákos Vandra
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

[tcpdump-workers] Test

[Akos Vandra]

Hi!

As I have not received any response to my last 3-4 emails to the list,
can someone please confirm that my emails are getting in?

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

[tcpdump-workers] Fwd: New datasource implementation

[Akos Vandra]

I might have had some email-difficulitites, I am not sure if my email
got to the list, so I am sending it in.

Please help me, if possible.

Regards,
  Ákos


-- Forwarded message --
From: Akos Vandra 
Date: 17 December 2011 17:54
Subject: New datasource implementation
To: tcpdump-workers@lists.tcpdump.org


Hi!

I have just written support for one of my CAN->USB adapter gadgets, so
that it would work with libpcap and thus with wireshark. I would love
to see support for my device as an option in future releases.

This is a USB adapter, and I am using libusb-1.0 to communicate with
the device. So in order for it to work, I need to libusb-1.0 linked as
well.

At the moment I am using a script-generated code to load the library
run-time, and load all the symbols to the according function pointers.
I am not very familiar with how dynamic libraries are linked, and
didn't want to hack around the makefiles too much.

So my questions are:
 - What are the steps needed to 'nicely' add support to a new device?
What do I have to add to the configuration, makefiles, #ifdefs, to add
conditional building?
 - How can I commit my newly supported device to the libpcap tree?
 - How can this libusb dependency be solved? I don't think it would
be fair to require all libpcap users to need libusb, just for one
device that they might not even use - conditional building might solve
this though.

Regards,
 Ákos Vandra
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] Fwd: New datasource implementation

[Akos Vandra]

Hi,

On 20 December 2011 15:36, Michael Richardson  wrote:
>
>>>>>> "Akos" == Akos Vandra  writes:
>    Akos> At the moment I am using a script-generated code to load the
>    Akos> library run-time, and load all the symbols to the according
>    Akos> function pointers.  I am not very familiar with how dynamic
>
> uhm, okay, but why?

When building wireshark based on the new libpcap with my module using
libusb-1.0, it didn't build, because it was missing symbols
(naturally, as wireshark didn't know it has to link libusb-1.0 as
well). So insted of digging into where I have to add them, it seemed
simpler to write a script.
Also it seems unnatural that only for my project wireshark, and any
other project using libpcap must use libusb-1.0...

>
>    Akos> So my questions are:  - What are the steps needed to 'nicely'
>    Akos> add support to a new device?  What do I have to add to the
>    Akos> configuration, makefiles, #ifdefs, to add conditional
>    Akos> building?   - How can I commit my newly supported device to
>    Akos> the libpcap tree?   - How can this libusb dependency be
>    Akos> solved? I don't think it would be fair to require all libpcap
>    Akos> users to need libusb, just for one device that they might not
>    Akos> even use - conditional building might solve this though.
>
> ./configure takes care of this.  libusb (and your code) would get used
> if the library exists.

I'm not quite sure I understand this. How would ./configure know that
that the libusb_claim_interface is in the libusb-1.0 library?
I'm sorry if I'm a bit slow here, I'm quite unfamiliar with autobuild
and autoconf, should look into them soon.

>
> Fork the code on github.com, and start patching, and ask us to review.
>

Allright, I started reading a tutorial on git and github, I only used
svn, and resisted git up until now. Don't really know why though.
But it seems more and more likely that if I will ever want to
contribute to an OS project, I must learn it, also it seems like a
nice tool...

Will get back to you as soon as I can create the commit.
Is there a how-to guide to how to add a new module to libpcap? Most OS
projects have a HACKING file, or something similar that would help me
get started on where to begin modifying...
My best guess would be to add a few lines to pcap-linux.c, to the
platfrom findalldevs function, between #ifdefs, but a guide would be
very nice to have.
If you can help me out with any nice documentation (on libpcap code
organization, or git/github) I would be very happy if you sent it to
me.

Regards,
  Ákos Vandra

> --
> ]       He who is tired of Weird Al is tired of life!           |  firewalls  
> [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net 
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
> driver[
>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>                       then sign the petition.
> -
> 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.

Re: [tcpdump-workers] Fwd: New datasource implementation

[Akos Vandra]

Mkay, I think I did it... Although I'm not sure :)

@Guy Harris: I dropped the ARM trace thing, it turned out that
wireshark is not really suitable for what I want to do. This is
another project, that adds support for a canusb adapter, and uses
DLT_SOCKETCAN, so there is no need for a new DLT.

Please check: axos88/libpcap.git

Regards,
  Ákos Vandra

P.S. Why are configure and config.h.in tracked? Shouldn't these be
generated by autoconf and autoheader?

On 22 December 2011 20:01, Michael Richardson  wrote:
>
>    Gisle> This is what I do (and what the sourceforge page [1]
>    Gisle> states). 1st time checkout: git clone
>    Gisle> git://bpf.tcpdump.org/libpcap
>
> Alternatively, visit github, get an account, upload your ssh public key,
> etc.
> Visit github.com/mcr/tcpdump, and fork the code.
> Then use the github's URL, like:
>     git clone g...@github.com:myname/tcpdump.git
>
> and then push to that repo, and ask me to do a pullup.
>
> The two methods are *NOT* mutually exclusive.  Assuming that you already
> git the clone from bpf.tcpdump,org,  you can do the github fork, and do:
>    cd libpcap
>    git remote add github g...@github.com:myname/libpcap.git
>    git push github master
>
> (that's how I get the merged code from github back onto
> bpf.tcpdump.org...)
>
> Since git can publish over HTTP, you can even just tar/ssh, scp, or
> symlink your repo into your web space, and say "here is the URL", but
> there are some limitations of http: URLs relating to caches, and
> compression and the like.
>
> --
> ]       He who is tired of Weird Al is tired of life!           |  firewalls  
> [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net 
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
> driver[
>   Kyoto Plus: watch the video 
>                       then sign the petition.
> -
> 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.

Re: [tcpdump-workers] Fwd: New datasource implementation

[Akos Vandra]

No, it doesn't. It's a device designed by myself, I just adjusted its
output format to be the same as DLT_SOCKETCAN expects.

Regards,
  Ákos Vandr

On 23 December 2011 03:58, Guy Harris  wrote:
>
> On Dec 22, 2011, at 5:51 PM, Akos Vandra wrote:
>
>> This is another project, that adds support for a canusb adapter,
>
> So this adapter doesn't just show up as a regular SocketCAN network adapter 
> when you plug it in?-
> 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.

[tcpdump-workers] Wrote a little guide for people getting started.

[Akos Vandra]

Hi!

I just wrote a little guide, based on my own experiences on how to add
a new datasource and how to contribute code to the libpcap project,
because I found this information quite hard to figure out by myself.

I added a new file named HACKING, and pushed it to my github port,
axos88/libpcap.git.

Some information out there is only intuition, some come from my own
experiences, and probably there are a few stuff that are not quite as
I think they are. Even so I think it's a good start, and it's a good
idea to have something like that.

Please read it, correct it where needed, and tell me your opinions, I
think it would help a lot if it made itself into the main source tree.
Also - as not a native speaker - I'm sure there are quite a few
spelling mistakes as well.

To be easier, I attached the file below:

Regards,
  Ákos Vandra

This file is intended to be a quick guide on how to contribute to the  libpcap
project. It's purpose is to help people to get to know how the project is
organized, and help them to join and contribute.

Please extend this file with any information that you consider useful, or
better yet, any information that would have made it easier for you to join.

At time of writing I'm also just beginning to get a grasp of what and how,
so some information here might be trivial, but it still might be helpful
for somebody.

Version list:
  2011.12.27. by Vandra Ákos - initial creation, two sections:
   adding a new 
data source
   contributing 
code

---
 Adding a new data source to libpcap
---

I have addded support for the canusb device, so I'll be presenting my
workflow based on it. Please use the dates in the version list and
refer to my code during reading if needed.

Every datasource has 2 parts:
  - Discovering the devices present
  - Opening and capturing data from the devices

To add support for another, new device one has to add these two functionalities
and register the new code with the main libpcap sources.

Step 1.
Come up with a name for your datasource. My source's name is 
"canusb"
Step 2.
Add a new header and source file to the libpcap directory, 
usually named
"pcap-$NAME-$PLATFORM.c"
If your datasource is not platform-dependent, you may leave out 
the
$PLATFORM part.
For me, it was "pcap-canusb-linux.c"
Step 3.
Usually all functions in these source files will be named 
$NAME_XXX like
canusb_create, canusb_platform_finddevs, etc, and will be made 
static,
unless they are needed somewhere in the libpcap source.
In my case only two interface functions, create and 
platform_finddevs
were needed to be made non-static.
Step 4.
Add interface for device discovery.

Usually, if your datasource is platform dependent, you will add 
a
fucntion named $NAME_platform_finddevs, which is responsible for
detecting any present devices, and adding them to the device 
list.

It's prototype is:

int canusb_platform_finddevs(pcap_if_t **alldevsp, char 
*err_str);

It should do any discovery necessary, and add each found device 
with a
call to

pcap_add_if(alldevsp, dev_name, 0, dev_descr, err_str)

where dev_name is the name of the device and dev_descr is a
human-readable description of it.

if the pcap_add_if returns a negative number, your function 
should bail,
free any allocated resources and return -1.
if the discovery is successful, it should return the number of 
found
devices.

Step 5.
Add interface for creating a handle to your device.

Capturing from device is usually a three-step procedure:
  - creating the device handle
  - activating the device for reading
  - doing the reading itself.

Creating the device should not do anything else but what is 
absolutely
necessary to see if the device is not only present, but we have 
the
necessary permissions to open it, and read from it.

As libpcap doesn't know anything about how our device works, 
creating
the device is also responsible for pointing out the function 
which
can do the device activation - using the pcap_t structure 

Re: [tcpdump-workers] Wrote a little guide for people getting started.

[Akos Vandra]

Yeah, I forgot to push it to the remote repo, now it should be there.

Ákos

On 28 December 2011 00:07, Guy Harris  wrote:
>
> On Dec 27, 2011, at 12:53 PM, Michael Richardson wrote:
>
>> I plan to let a 4.1.2 (perhaps a 4.2) out tomorrow.
>
> Do you mean "4.1.2" or "4.2.1"?  4.2.0, and libpcap 1.2.0, are the current 
> release, according to the Web site.  Both of them have significant bugs that 
> are fixed in the current 4.2 and 1.2 branches.
>
> Presumably they'll be announced on tcpdump-announce - I missed the 
> 4.2.0/1.2.0 releases as there wasn't an announcement.-
> 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.

Re: [tcpdump-workers] New datasource implementation

[Akos Vandra]

Hi!

Yes, I have thought about it, but when I started writing the pcap
driver, I didn't know about socketcan, and this user-space driver was
already mostly ready (had to be ported a wee bit from c++), as I have
used an own program to display the can frames before.

Problem is, I'm not sure I have the courage to start kernel driver
development :) and I had a hard time finding information on how a
socketcan driver should behave on the net with a few google searches.

Another approach would be to rewrite the interface on the
microcontroller itself, but again I have no idea what requests and
responses a usb-socketcan device should implement, and I am having
quite a hard time with the USB peripheral, because it is only scarcely
documented in the user manual.

So for now I think I'll stick with the libusb-based driver, and maybe
add more or less native support for socketcan later on. Also I'm not
sure if m$ windows supports socketcan?

Regards,
  Ákos


On 28 December 2011 12:23, Felix Obenhuber  wrote:
> Hi,
>
> On Sat, 2011-12-17 at 17:54 +0100, Akos Vandra wrote:
>> I have just written support for one of my CAN->USB adapter gadgets, so
>> that it would work with libpcap and thus with wireshark. I would love
>> to see support for my device as an option in future releases.
>
> Did you think about writing a SocketCAN driver for your device?
> PCAP already has support for SocketCAN. Furthermore the SocketCAN
> interface is very well established and comes with drivers for lots of
> CAN hardware.
>
> cheers,
>
> Felix
>
> -
> 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.

[tcpdump-workers] Initializing a device

[Akos Vandra]

Hi!

When opening a capture device, is it possible to hand off some
initialization data to the libpcap handler?

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? (btw, I don't
really understand what BPF filters are, where can I get some
documentation on this?)

is the inject_op operation for sending data through the device?

Regards,
  Ákos Vandra
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] Initializing a device

[Akos Vandra]

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  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=" 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

Re: [tcpdump-workers] Initializing a device

[Akos Vandra]

Hi!

I have read through the threads you mentioned, it's nice to see that
something similar has already been suggested, I would like to present
a few new arguments in favor of them.

On 6 January 2012 12:15, Guy Harris  wrote:
>
> On Jan 5, 2012, at 1:40 AM, Akos Vandra wrote:
>
>> 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?
>
> There isn't one.  I've used "device-type module" later in this message.  
> "iface" is close to "interface", and that could be confused with "interface" 
> in the sense of a network interface, on which you might do capture.

Okay, we should settle on some name like device-type module, or
capture module before talking about this gets too confusing - you
chose. :)

>
>> 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,
>
> No, we wouldn't need to (and we wouldn't ever do so, as that'd break source 
> and binary compatibility).
>

...

> Programs that need to use *any* capabilities not provided by 
> pcap_open_live(), such as setting the kernel capture buffer size, setting 
> monitor mode on 802.11 interfaces, or setting the time stamp type, must use 
> the newer APIs - pcap_create(), the appropriate setter routines, and 
> pcap_activate().
>
>> 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.
>
> The current API was chosen during a discussion on the tcpdump-workers mailing 
> list back in 2008.
>
> "I.e. we should instead have a new pcap_open() call, and then we should
> have a serious of calls that set various options or ask for various
> things based upon that handle."
>
>> 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.
>
> Something along those lines was proposed in that thread:
>
>        http://thread.gmane.org/gmane.network.tcpdump.devel/2800/focus=2818
>
> and that proposal evolved:
>
>        http://thread.gmane.org/gmane.network.tcpdump.devel/2800/focus=2819
>
>        http://thread.gmane.org/gmane.network.tcpdump.devel/2800/focus=2820
>
>        http://thread.gmane.org/gmane.network.tcpdump.devel/2800/focus=2822
>
>        http://thread.gmane.org/gmane.network.tcpdump.devel/2800/focus=2823
>
>        http://thread.gmane.org/gmane.network.tcpdump.devel/2800/focus=2824
>
>        http://thread.gmane.org/gmane.network.tcpdump.devel/2800/focus=2826
>
> and then Michael Richardson said
>
>        http://thread.gmane.org/gmane.network.tcpdump.devel/2800/focus=2828
>
> which, shortly afterwards, got us moving in the direction of his suggestion.
>
> An API pattern based on a list of parameters is more complicated than the 
> current API pattern, as you have to create and manipulate the list.
>
> One disadvantage of the current API pattern is that it can't handle new 
> parameters added by new device-type modules without changing the core API.

Yeah, this is what I was trying to point out, an

Re: [tcpdump-workers] Initializing a device

[Akos Vandra]

On 6 January 2012 17:16, Jakub Zawadzki  wrote:
> On Fri, Jan 06, 2012 at 04:47:09PM +0100, Akos Vandra wrote:
>> Another reason why this is not a good approach: Let's get wireshark in
>> the picture. Let's say the user selected a canusb device. The only way
>> for wireshark to know what parameters (ex. baudrate) the canusb device
>> needs is if wireshark knows how the canusb device works. This is bad.
>> IMHO one of the main goals of libpcap would be to hide how the capture
>> device actually works from the user application, so that it can use a
>> device-independent way of getting packets.
>
> IMHO user need to know what parameters he can (or need to) set, and
> 1/ He can use either enviroment variables,
> like:
>  CANUSB_BAUDRATE=2400 tcpdump -i canusb0
>  USBRADIO0_CHANNEL=12 tcpdump -i usbradio0
>
> 2/ Capture from interfaces like:
>  tcpdump -i canusb0:baudrate=2400,parity
> or
>  tcpdump -i usbradio0:channel=12
>
> I used something like (2/) in nflog cause there was no other way,
>
> but I agree possibility to add custom parameters would be great, and much
> more user friendly!
>

Does this work for child processes? For example wireshark uses a child
process for reading in capture data, do environment variables
propagate to child processes on every platform? I would find it
logical, but wouldn't be surprised if not...
If yes, this would be a good hack, I aggree, but - as you said - it is
very user unfriendly, and probably only for advanced users, not to
mention windows users - not to degrade them or anything, but I find
using cmd line parameters on windows is a harder and more odd than on
linux for example...

>>   - wireshark repeadetly calls pcap_setparam_int(id, value) or
>> pcap_setparam_bool(id, value), or whatever, which checks for parameter
>> type safety, and calls the capture module's pcap_setparam(id, &value).
>> (Dereferencing will be safe as the API already checked for type
>> safety. This idea is from the wireshark API, a few basic types will be
>> supported, like UINT, INT, BOOL, ENUM, etc.
>
> Let's have just:
>  int pcap_setparam(pcap_t *p, const char *param, const char *value)
>
> If param is not understand, or value is invalid for given param (like: not 
> integer)
> it should return -1.

Yeah, this would simplify the API.
The other side to this argument is that if the application wants to
set some calculated value, then it needs to put that into a string,
call this function, which will parse it back to an integer. It's not
efficient, but I don't really think this is a problem as we don't do
it often - only when opening a device, or at least with our current
model. And even if later this would be used for an already live pcap
handler, I doubt it would be called too often.

Maybe even the _uint, _bool, _int64, etc. calls could be only wraps
around this one to simplify things in some cases.

Regards,
  Ákos Vandra

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

Re: [tcpdump-workers] Initializing a device

[Akos Vandra]

We could put a limit - say 32 or 64 chars - to the max length of the
param, and then allocate in on the stack, but it would still require
printf.
In this form, as we are going to have a single interface function to
set and read the parameter, some serialization and deserialization of
the data is necessary... Either that, or the interface has to be
changed to somehow accomodate multiple type input parameters...
Varargs maybe?

Regards,
  Ákos

On 11 January 2012 10:24, Guy Harris  wrote:
>
> On Jan 6, 2012, at 2:16 PM, Akos Vandra wrote:
>
>> On 6 January 2012 17:16, Jakub Zawadzki  wrote:
>>
>>> Let's have just:
>>>  int pcap_setparam(pcap_t *p, const char *param, const char *value)
>>>
>>> If param is not understand, or value is invalid for given param (like: not 
>>> integer)
>>> it should return -1.
>>
>> Yeah, this would simplify the API.
>> The other side to this argument is that if the application wants to
>> set some calculated value, then it needs to put that into a string,
>> call this function, which will parse it back to an integer. It's not
>> efficient, but I don't really think this is a problem as we don't do
>> it often - only when opening a device, or at least with our current
>> model. And even if later this would be used for an already live pcap
>> handler, I doubt it would be called too often.
>>
>> Maybe even the _uint, _bool, _int64, etc. calls could be only wraps
>> around this one to simplify things in some cases.
>
> Once you've done that, whether they're wrappers or not is just an 
> implementation detail; pcap_setparam() would be something you use for user 
> text input (command-line and text-widget), and the other pcap_setparam_XXX() 
> calls would be used for:
>
>        user non-text input (checkboxes that would return a Boolean, spinboxes 
> that would return a number, combo boxes/option menus that would return an 
> enum value, etc.), as having to convert from those input values to text would 
> be an extra burden;
>
>        calculated input where you'd again need to convert to text (for 
> constant input you could use a constant string).
>
> My concern is less with the CPU efficiency than with the programmer 
> efficiency - I'd rather not have to have to use asprintf() or whatever.
> 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.

Re: [tcpdump-workers] Initializing a device

[Akos Vandra]

On 12 January 2012 10:38, Guy Harris  wrote:
>
> On Jan 12, 2012, at 1:06 AM, Akos Vandra wrote:
>
>> We could put a limit - say 32 or 64 chars - to the max length of the
>> param, and then allocate in on the stack, but it would still require
>> printf.
>
> Where would that be done?  It's a little more convenient than using routines 
> such as asprintf() and g_sprintf(), because you don't have to free the 
> result, but it's still extra work.

In the wrapper functions (setparam_xxx)
for ex something like this:

int setparam_uint64(pcap_t * pcap, char* param, uint64_t value)
{
  char[64] buf;
  sprintf(buf, "%lu", value);
  return pcap->setparam_op(param, buf);  //Add check for NULL op
}

>
>> In this form, as we are going to have a single interface function to
>> set and read the parameter,
>
> Which form is that?

That we use only one function ptr to set and get parameter values,
which uses char* as parameters.

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

Re: [tcpdump-workers] Initializing a device

[Akos Vandra]

Hi!

What's your opinions on this? If you aggree, I would start doing some
initial coding sometime in the next few days, and then we can continue
the debate from there - unless I missed that it was dismissed.

Regards,
  Ákos Vandra

On 12 January 2012 11:43, Akos Vandra  wrote:
> On 12 January 2012 10:38, Guy Harris  wrote:
>>
>> On Jan 12, 2012, at 1:06 AM, Akos Vandra wrote:
>>
>>> We could put a limit - say 32 or 64 chars - to the max length of the
>>> param, and then allocate in on the stack, but it would still require
>>> printf.
>>
>> Where would that be done?  It's a little more convenient than using routines 
>> such as asprintf() and g_sprintf(), because you don't have to free the 
>> result, but it's still extra work.
>
> In the wrapper functions (setparam_xxx)
> for ex something like this:
>
> int setparam_uint64(pcap_t * pcap, char* param, uint64_t value)
> {
>  char[64] buf;
>  sprintf(buf, "%lu", value);
>  return pcap->setparam_op(param, buf);  //Add check for NULL op
> }
>
>>
>>> In this form, as we are going to have a single interface function to
>>> set and read the parameter,
>>
>> Which form is that?
>
> That we use only one function ptr to set and get parameter values,
> which uses char* as parameters.
>
>> -
>> 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.