thank you! ubuntu: Linux 3.13.0-61-generic fedora: Linux 3.11.10-100-fc18.x86_64
On Tue, Oct 13, 2015 at 1:37 AM, Guy Harris <g...@alum.mit.edu> wrote: > > On Oct 12, 2015, at 4:01 PM, liu wen <caonimagongl...@gmail.com> wrote: > > > On Oct 12, 2015, at 1:53 PM, liu wen <caonimagongl...@gmail.com> wrote: > > > >>> I tried the program (compile and then run) on two laptops, one > with Fedora (fedora release 18) and one with Ubuntu (Ubuntu 14.04.2 LTS) > >>> on Fedora, the program works fine, the pcap_dispatch() can capture > packets the first time it is invoked, but on Ubuntu, as previously > mentioned, the first two invoke of pcap_dispatch() return 0. I use ldd > to check the libraries of this program on each laptop. > >>> > >>> Fedora: > >>> $ldd relay > >>> linux-vdso.so.1 => (0x00007fff1d1ad000) > >>> libevent-1.4.so.2 => /lib/libevent-1.4.so.2 (0x00007faca467d000) > >>> libpcap.so.1 => /lib64/libpcap.so.1 (0x00000035b4a00000) > >>> libc.so.6 => /lib64/libc.so.6 (0x00000035b0a00000) > >>> libnsl.so.1 => /lib64/libnsl.so.1 (0x00000035cea00000) > >>> librt.so.1 => /lib64/librt.so.1 (0x00000035b1a00000) > >>> libresolv.so.2 => /lib64/libresolv.so.2 (0x00000035b2e00000) > >>> /lib64/ld-linux-x86-64.so.2 (0x00000035b0200000) > >>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00000035b1600000) > >>> > >>> > >>> ubuntu: > >>> > >>> $ ldd relay > >>> linux-vdso.so.1 => (0x00007ffd08bc5000) > >>> libevent-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5 > (0x00007eff35f81000) > >>> libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 > (0x00007eff35d43000) > >>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff3597e000) > >>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x00007eff35760000) > >>> /lib64/ld-linux-x86-64.so.2 (0x00007eff361c5000) > >>> > >>> > >>> indeed, both libpcap and libevent versions are different. > >> > >> That's because Fedora and Ubuntu are different. :-) > >> > >> Linux distributions may, or may not, use the library developer's > upstream version number as the shared library version number. It looks as > if Fedora and Ubuntu are using the upstream version numbers for libevent, > but Linux distributions tend *not* to use the libpcap upstream version > number, for various reasons. (One of which is that the API and ABI for > libpcap have been stable since before libpcap 1.0; I guess the Debian > people decided that it became stable in 0.8, even though it was stable > before then, and have been using "0.8" as the libpcap shared library > version number ever since then, even for 1.x versions of libpcap.) > >> > >> To find out the version number of libpcap, try > >> > >> tcpdump -h > >> > >> to get the *actual* version number, rather than the shared library > version number, of the system libpcap, as that's what tcpdump uses and it's > what you're using (based on the pathnames from ldd). > >> > >> The Linux kernel number also matters here, as the underlying capture > mechanism is provided by the kernel, and that's what would be doing the > timeout. > > > > what do you mean of upstream version? > > I mean "the version number from the developer of the library". > > libevent: > > http://libevent.org > > mentions both 1.4.15 and 2.0.22 versions, as well as older 1.4 and 2.0 > versions. > > I infer from the "1.4" in "libevent-1.4.so.2" that Fedora 18's libevent is > one of the 1.14.x versions. > > I infer from the "2.0" in "libevent-2.0.so.5" that Ubuntu 14.04's libevent > is one of the 2.0.x versions. > > > version 2 is upstream version of version 1 or version 1 is upstream > version of version 2? > > "Upstream" has nothing to do with the numerical values of version > numbers. It has to do with the notion of software in a Linux distribution > coming from a developer or group of developers for that particular piece of > software and "flowing downstream" to a Linux distributor who takes it and > adds it to their distribution (possibly after applying their own patches). > > > I tried tcpdump -h on Fedora laptop and Ubuntu laptop and the result is: > > on Fedora: > > > > tcpdump version 4.3.0 > > libpcap version 1.3.0 > > > > on Ubuntu: > > tcpdump version 4.5.1 > > libpcap version 1.5.3 > > > > how are these libpcap version number related to libpcap.so.1 and > libpcap.so.0.8? > > They are not at all related. > > A Linux distribution could call libpcap 0.8.1, 1.2.0, 1.3.0, 1.5.0, 1.7.4, > whatever "libpcap.so.1" or "libpcap.so.2" or "libpcap.so.0.8" or > "libpcap.so.17.168" or whatever they choose to do. They could also give > them names such as "libpcap-0.8.1.so.0.8", "libpcap-1.3.0.so.1", etc. > (presumably with a symbolic link named "libpcap.so.0.8" to > "libpcap-0.8.1.so.0.8", a symbolic link named "libpcap.so.1" to > "libpcap-1.3.0.so.1", etc., so that the program using the library doesn't > have a very specific version of the library wired into it and could still > use libpcap 1.7.4 even if it was originally built with libpcap 1.3.0. > > > besides, I'm not very clear whether I understand you correctly. I use > "ldd" on the program relay to show what libraries they are using. > > It will tell you the pathnames of the libraries. It will *NOT* tell you > whether it's libpcap 1.3.0 or libpcap 1.5.3 or libpcap 0.7.1 or libpcap > 1.7.4 or..., unless that information is in the pathname. > > > So you mean the libraries shown on ldd results are not the real > libraries they are using? > > No, I mean that ldd doesn't tell you the upstream library release version > numbers, they just give you the OS's shared library version number. If a > new version of a library comes out, and it's compatible with the older > version, the shared library version number should *NOT* be changed, even > though the upstream version number of the library changed, so that programs > linked with the older shared library will be able to use the new shared > library. > > > I really don't understand why on ubuntu, the program can't run > correctly as expected and how to make it work properly on ubuntu. > > I need to know the kernel version numbers on those machines to determine > what is happening. Please run "uname -sr" on both machines and show the > results. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
