Re: [tcpdump-workers] Initializing a device
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 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.
Re: [tcpdump-workers] Initializing a device
On Wed, 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? I'm not a developer of libpcap/tcpdump, but I don't think so. > 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. Isn't this the kind of thing that would be set up before hand? Kindof like you don't setup an ethernet device with libpcap, you set it up with ifconfig or whatever, and then use it with libpcap. baud rate makes it sound like it should respond to the termios system calls, or be configurable with stty, and a user would make setting permanent use rc scripts, or a udev rule. Or if they need to use some tool specific to your can device, then you'd provide that tool. > Would it be possible to use the BPF filter for this? I doubt it. Filters are a mini assembly language run on packets to see if they should be selected for capture. The tcpdump command line filter expression is compiled into the assembly language. Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Initializing a device
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] Fwd: New datasource implementation
> Do you have any references for this, so I can see exactly > what it means? > > If it just means that if you build an executable image (or > shared library), linking it with library A, and library A is > a shared that is linked with library B, and if the executable > image is *not* linked with library B when you build it, if > the image refers to routines in library B those references > will *not* be treated as resolved by virtue of library B > being dragged in by library B, that doesn't appear to break > the scenario I describe. This comes from reading the NetBSD 'pkgsrc' mailing list, where some packages are failing to build with newer versions of 'gld'. The 'solution' (which isn't really one) is a linker option to copy DT_NEEDED entries from refernced libraries into the program image. > > This breaks many things! > > Does it, in particular, break the scenario I describe? If I misunderstood your senario, maybe not! But consider something like: I have an old product 'A' that is releases liba.so. I now write a new product 'B' that shares quite a lot of code with product 'A', so i generate a libab.so containing the common parts, and build liba.so with a DT_NEEDED entry for libab.so (and build libb.so). I would like existing program binaries and makefiles to still work unchanged. David - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
