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.
Re: [tcpdump-workers] Fwd: New datasource implementation
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 linker will see that the first library requires the second library and will load and bind it in at run-time. The gnu/linux folks have recently changed the behaviour of gld (probably contrary to the elf specification, but they tend not to care about standards) so that linker will not assume that libraries referenced by DT_NEEDED entries in other libraries have their symbols made available to teh main program. This breaks many things! (It also stops you implementing a shared library in separate pieces.) What happens at run time depends on the dynamic linker. David - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Fwd: New datasource implementation
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 libraries, the program will still work - the run-time linker will see that the first library requires the second library and will load and bind it in at run-time. The gnu/linux folks have recently changed the behaviour of gld (probably contrary to the elf specification, but they tend not to care about standards) I either no longer have my old dead-tree SVR4 ABI documents or have them buried in a box somewhere that's probably in storage, but the version at http://www.sco.com/developers/devspecs/gabi41.pdf says Shared Object Dependencies When the link editor processes an archive library, it extracts library members and copies them into the output object file. These statically linked services are available during execution without involving the dynamic linker. Shared objects also provide services, and the dynamic linker must attach the proper shared object files to the process image for execution. When the dynamic linker creates the memory segments for an object file, the dependencies (recorded in DT_NEEDED entries of the dynamic structure) tell what shared objects are needed to supply the program’s services. By repeatedly con- necting referenced shared objects and their dependencies, the dynamic linker builds a complete process image. When resolving symbolic references, the dynamic linker examines the symbol tables with a breadth-first search. That is, it first looks at the symbol table of the executable program itself, then at the symbol tables of the DT_NEEDED entries (in order), then at the second level DT_NEEDED entries, and so on. Shared object files must be readable by the process; other per- missions are not required. That doesn't seem to specify anything about what the link editor, as opposed to the dynamic linker, must do about DT_NEEDED structures. so that linker will not assume that libraries referenced by DT_NEEDED entries in other libraries have their symbols made available to teh main program. 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 breaks many things! Does it, in particular, break the scenario I describe? What happens at run time depends on the dynamic linker. If, with some dynamic linker, it means that if an executable image is linked with library A, and is not linked with library B and does not use anything from library B, and library A is linked with library B and does use things from library B, then, when that executable image is run, symbols from library B are not available to the main program, that doesn't break my scenario, and I'm not sure what useful things it would break. If, with some dynamic linker, it means that if an executable image is linked with libraries A and B, and does use thinks from library B, and library A is linked with library B and does use things from library B, then, when that executable image is run, symbols from library B are not available to the main program, that would be Very Bad and Very Stupid. Would there be any dynamic linkers that work that way? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Fwd: New datasource implementation
Akos == Akos Vandra axo...@gmail.com 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 canusb adapter, Akos and uses DLT_SOCKETCAN, so there is no need for a new DLT. Akos Please check: axos88/libpcap.git Akos Regards, Ákos Vandra 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* version of those utilities installed, and only people hacking that part of the code need it. If you touch .devel in the directory, configure does some more things, including running make depend. Hmm. I thought it also assumed autoconf existed, and would regenerate things, but I don't see that in ./configure. -- ] 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.
Re: [tcpdump-workers] Fwd: New datasource implementation
On Dec 27, 2011, at 12:58 PM, Michael Richardson wrote: Akos == Akos Vandra axo...@gmail.com 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* version of those utilities installed, and only people hacking that part of the code need it. The distribution tarballs should definitely include configure and config.h.in - but they could be generated by the process of making the release tarball; that's how Wireshark does it. That way, end users don't need to have autoconf or autoheader installed at all, much less having the right version installed; as you note, the people hacking on the configure scripts would need to have them installed anyway. If you touch .devel in the directory, configure does some more things, including running make depend. Hmm. I thought it also assumed autoconf existed, and would regenerate things, but I don't see that in ./configure. Yes, we'd want Makefile rules to generate the configure script, and make the release tarball depend on configure so that those rules are run when you do make releasetar.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Fwd: New datasource implementation
Guy Harris g...@alum.mit.edu 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 to update. But using Sourceforge to commit patches and feature requests is not ideal IMHO (besides SF is so slow). Why not send patches to this list so reach a larger audience of critical readers? [1] http://www.tcpdump.org/#source --gv - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Fwd: New datasource implementation
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 m...@sandelman.ca 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 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
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
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 g...@alum.mit.edu 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.
Re: [tcpdump-workers] Fwd: New datasource implementation
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 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...
Use in what sense?
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 linker will see that the
first library requires the second library and will load and bind it in at
run-time.
Only if the program is explicitly linked with a *static* version of the first
library, or if it's being linked with a dynamic version of the first library
that wasn't explicitly linked with a dynamic version of the second library,
does it also need to be linked with a static version of the second library.
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.
It's unfortunately not trivial to do this, but it is possible.
If libpcap should, by default, support your new device if libusb is available
on your machine (which, for most Linux distributions, means the development
package for libusb must be installed on the machine on which you're building
libpcap), with a --disable-{whatever} option available to let the user
configure libpcap *not* to support your new device, I'd look at, for example,
the code in configure.in for Bluetooth capturing - look for enable Bluetooth
support. It lets you configure:
with no options, in which case it'll look for the bluetooth.h header
and include Bluetooth support if and only if it's present;
with --disable-bluetooth, in which case it will leave the Bluetooth
support out, even if the header is there.
If all versions of libusb have all the routines you need, checking for a header
file for libusb is sufficient. (Checking for the *library* is not sufficient;
this probably being Linux, you might have the libusb package installed, so that
you have a dynamic library for the benefit of programs built with that library,
but *not* have the libusb-dev package installed, so you don't have the header
files needed in order to build code that uses libusb.)
If not all versions of libusb have those routines, you'll have to use a macro
such as AC_CHECK_LIB to see whether libusb exists and has the function or
functions in question.
Is there a how-to guide to how to add a new module to libpcap?
Unfortunately, no. The mechanisms for doing so were originally created as
somewhat specialized hacks, and have been slowly turning into less-specialized
mechanisms, but it's still not as clean as arguably should be the case.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Fwd: New datasource implementation
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 assigned; that means supplying an indication of the packet header format or, at least, a link to such a specification, even if it's one of ARM's damned sorry, you have to be a customer to see this document documents. What do I have to add to the configuration, makefiles, #ifdefs, to add conditional building? See how, for example, the Linux Bluetooth support was added. - How can I commit my newly supported device to the libpcap tree? 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?). - 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. I guess that depends on what need means here. As I noted in my other message, if libpcap is dynamically linked with libusb, libusb will be linked in at run time without programs using libpcap, or their developers, needing to know about it.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Fwd: New datasource implementation
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 axo...@gmail.com 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 == Akos Vandra axo...@gmail.com 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 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. Fork the code on github.com, and start patching, and ask us to review. -- ] 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.
Re: [tcpdump-workers] Fwd: New datasource implementation
Hi, On 20 December 2011 15:36, Michael Richardson m...@sandelman.ca wrote: Akos == Akos Vandra axo...@gmail.com 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.
