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 wrote:
>
> On Oct 12, 2015, at 4:01 PM, liu wen wrote:
>
> > On Oct 12, 2015, at 1:53 PM, liu wen 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 => (0x7fff1d1ad000)
> >>> libevent-1.4.so.2 => /lib/libevent-1.4.so.2 (0x7faca467d000)
> >>> libpcap.so.1 => /lib64/libpcap.so.1 (0x0035b4a0)
> >>> libc.so.6 => /lib64/libc.so.6 (0x0035b0a0)
> >>> libnsl.so.1 => /lib64/libnsl.so.1 (0x0035cea0)
> >>> librt.so.1 => /lib64/librt.so.1 (0x0035b1a0)
> >>> libresolv.so.2 => /lib64/libresolv.so.2 (0x0035b2e0)
> >>> /lib64/ld-linux-x86-64.so.2 (0x0035b020)
> >>> libpthread.so.0 => /lib64/libpthread.so.0 (0x0035b160)
> >>>
> >>>
> >>> ubuntu:
> >>>
> >>> $ ldd relay
> >>> linux-vdso.so.1 => (0x7ffd08bc5000)
> >>> libevent-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5
> (0x7eff35f81000)
> >>> libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8
> (0x7eff35d43000)
> >>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7eff3597e000)
> >>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7eff3576)
> >>> /lib64/ld-linux-x86-64.so.2 (0x7eff361c5000)
> >>>
> >>>
> >>> 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 orig
