Re: Initializing a device

[Jakub Zawadzki <darkjames-ws () darkjames pl>]

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!

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

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