Patches for libpcap, to use the new Linux Socket Filter option in 2.2 are
available here:
ftp://ftp.inr.ac.ru/ip-routing/lbl-tools/
or from a mirror:
ftp://ftp.gwdg.de/pub/linux/tux/people/alexey-kuznetsov/ip-routing/lbl-tools/
Christian
On Thu, 3 Dec 1998, Guy Harris wrote:
> > I would think, but without even having looked at NFR, that they are
> > referring to the Linux Socket Filter option in 2.2, which is equivalent to
> > the Berkeley Packet Filter except that it filters on a socket instead of a
> > device. LSF provides a BPF engine, so once libpcap is patched correctly, a
> > different section of code in libpcap will be used to do filtering, which
> > could remove that timeout problem.
>
> NFR's problem is, I infer from stuff I saw on their Web site, that
> there's no way in a standard Linux 2.0[.x] kernel to have the kernel
> throw out packets deemed "uninteresting" before copying them up to
> userland and waking up something reading from a SOCK_PACKET socket -
> every single packet on the network gets copied up to userland, and has
> to be filtered out there.
>
> Other systems' raw link layer access mechanisms typically have some way
> of passing a packet filter into the kernel, either BPF or CMU/Stanford
> stack-machine packet filter, so that most packets can be discarded
> without copying the entire captured contents to userland, thus saving a
> fair bit of CPU time, context switches, etc..
>
> I think the inability to do that, rather than the lack of a timeout, is
> what's causing NFR's problem; the machine can't keep up with the stream
> of packets coming in, because every one of those packets have to be
> copied up to NFR in userland. The page at
>
> http://www.nfr.com/nfr/NFR_FAQ.html
>
> says:
>
> Why does my Linux box not seem to be able to keep up with my
> network?
>
> Question:
>
> Seems that my Linux box is having trouble keeping up with the
> traffic on my network. I have tried a BSDI, Sun and FreeBSD
> version and they have no problems keeping up. What's wrong?
>
> Answer:
>
> We too have seen that. We noticed extremely high packet loss on
> a P90 Linux box while comparing it to *no* packet loss on a BSDI
> P75 on the same network at the same time. The difference in
> performance is a result of the use of a different mechanism to
> get packets off the wire. Linux does not have bpf calls in the
> NIC drivers, so libpcap uses an alternate mechanism to get
> packets out of the kernel. This mechanism does not appear to
> have been designed with performance in mind.
>
> If you are interested in the exact reasons that libpcap performs
> poorly on Linux see the function pcap_read() in pcap-linux.c
> Note that this function will be called for *every* packet read,
> and also that it loops through calls to recvfrom() and strcmp()
> at least once each time it is called. Compare this with the
> same function in pcap-bpf.c.
>
> We are considering possible approaches to this problem.
>
> The Linux Socket Filter should fix that, if the problem is what I think
> it is (although I'm a little suspicious, given that Solaris 2.x doesn't
> have BPF calls in its NIC drivers, either - and "libpcap", which NFR
> uses, doesn't try to compile filter expressions into CMU/Stanford packet
> filter code; perhaps NFR generates that code itself, uses
> "pcap_fileno()" to get the raw file descriptor for the DLPI device, and
> does its own "ioctl"s to install the filter, but can't do anything
> similar for Linux 2.0[.x] because there *is* no in-kernel filtering),
> but I don't *think* it'd remove the timeout problem.
>
> Then again, the timeout problem might just exist because LBL weren't
> given a patch to support the "to_ms" argument to "pcap_open_live()" on
> Linux, or because they haven't yet incorporated it into a "libpcap"
> release - I can't get to the K-Arp-Ski site for some reason, right now,
> so I can't check the patch that I think is there for "libpcap", but if
> it just adds support for the "to_ms" argument, that'd be sufficient to
> fix the timeout problem.
>
> (The URL for K-Arp-Ski in my bookmarks file is
>
> http://mojo.calyx.net/~btx/karpski.html
>
> but attempts to connect to port 80 of "mojo.calyx.net" get "Connection
> refused".
>
> If he doesn't have a patch for "libpcap" 0.4, I'll look into applying it
> to 0.4.)
>
