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

2012-01-04 Thread David Laight
> 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 w

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

2012-01-03 Thread Guy Harris
On Jan 3, 2012, at 1:23 AM, David Laight wrote: > >> On all modern UN*Xes, as far as I know, a dynamic library can >> be linked with another dynamic library, and if a program is >> explicitly linked with the first of those libraries, but >> *not* explicitly linked with the second of those lib

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

2012-01-03 Thread David Laight
> On all modern UN*Xes, as far as I know, a dynamic library can > be linked with another dynamic library, and if a program is > explicitly linked with the first of those libraries, but > *not* explicitly linked with the second of those libraries, > the program will still work - the run-time l

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

2011-12-27 Thread Guy Harris
On Dec 27, 2011, at 12:58 PM, Michael Richardson wrote: >> "Akos" == Akos Vandra writes: > >Akos> P.S. Why are configure and config.h.in tracked? Shouldn't >Akos> these be generated by autoconf and autoheader? > > In theory, yes. In practice, end users never have the exact *right*

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

2011-12-27 Thread Michael Richardson
> "Akos" == Akos Vandra writes: Akos> Mkay, I think I did it... Although I'm not sure :) Akos> @Guy Harris: I dropped the ARM trace thing, it turned out that Akos> wireshark is not really suitable for what I want to do. This Akos> is another project, that adds support for a c

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

2011-12-22 Thread 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

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

2011-12-22 Thread Guy Harris
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.

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

2011-12-22 Thread 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. Ple

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

2011-12-22 Thread Michael Richardson
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 gi

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

2011-12-22 Thread Michael Richardson
> "Akos" == Akos Vandra writes: Akos> When building wireshark based on the new libpcap with my Akos> module using libusb-1.0, it didn't build, because it was Akos> missing symbols (naturally, as wireshark didn't know it has to Akos> link libusb-1.0 as well). So insted of diggi

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

2011-12-22 Thread Gisle Vanem
"Guy Harris" wrote: Send us a patch, submit it on SourceForge, or do whatever the shiny new Git magic is for that (Michael, how do people do that?). This is what I do (and what the sourceforge page [1] states). 1st time checkout: git clone git://bpf.tcpdump.org/libpcap Then "git fetch"

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

2011-12-21 Thread Guy Harris
On Dec 20, 2011, at 1:01 AM, Akos Vandra wrote: > So my questions are: > - What are the steps needed to 'nicely' add support to a new device? If your new device requires a new link-layer header type (which this one does, as per the discussion on the wireshark-dev list), you need to get one ass

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

2011-12-21 Thread Guy Harris
On Dec 20, 2011, at 4:37 PM, Akos Vandra wrote: > 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

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

2011-12-20 Thread 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 wit

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

2011-12-20 Thread Michael Richardson
> "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? Akos> So my questions ar

[tcpdump-workers] Fwd: New datasource implementation

2011-12-20 Thread 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-w