Re: why does pcap_dispatch return 0?

[liu wen <caonimagongling () gmail com>]

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 <guy () alum mit edu> wrote:

> On Oct 12, 2015, at 4:01 PM, liu wen <caonimagongling () gmail com> wrote:
>
> > On Oct 12, 2015, at 1:53 PM, liu wen <caonimagongling () 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