Re: Initializing a device

[Akos Vandra <axos88 () gmail com>]

On 6 January 2012 17:16, Jakub Zawadzki <darkjames-ws () darkjames pl> 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.