SNIFFING: How do you evaluate this article?

Hui Tsang (
Mon, 19 Apr 1999 22:01:05 +0530


I append a message from the NFR (Network Flight Recorder)
Users mailing list.

The company (NFR) decided to not support Linux for its
sniffing product. One of their software engineers

Does the evaluation still hold?
Are there any mistakes?

I append the message. I would appreciate a point-wise
comparison (if possible).

Please let me know.


Linux packet capture (was RE: NAI Security Advisory: Vulnerability in NFR

Andrew Lambeth ( Sat, 20 Feb 1999 00:08:06 -0500

* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] * Next message: Jan B. Koum: "Re: NAI Security Advisory: Vulnerability in NFR 2.0.2-Research" * Previous message: dustin sallings: "Re: NAI Security Advisory: Vulnerability in NFR 2.0.2-Research" * In reply to: Derek Mezack: "Re: NAI Security Advisory: Vulnerability in NFR 2.0.2-Research"


I downloaded a copy of the latest Linux kernel sources I could find (2.2.1) and had a look to see how the packet capture inadequacies have been addressed. Here are my findings after a cursory examination of the code:


1. The 2.2 kernel includes a bpf-like filtering capability, called LSF (Linux Socket Filter.) This capability allows bpf-style filters to be applied to packets off the wire in the kernel. Since this means that only packets which pass the filter will be copied up to user-space, applications which need to see some *subset* of all packets on a network should see a dramatic increase in performance.

2. As far as I can see, no facility has been added for getting multiple whole packets (including the LLC header) out of the socket. (i.e. you still have to make a call to read() for each individual packet.)

3. Because the code in linux/net/packet/af_packet.c doesn't see each packet until after it has been massaged by the device driver to obscure the LLC header, it must "unmassage" it to include LLC info in the packet.

4. Though I admit that I didn't look very hard at this one, it still seems to me that there is no way to determine how many packets were dropped because the calling application was unable to handle them fast enough. They would appear to be discarded silently in linux/net/packet/af_packet.c after calls to sock_queue_rcv_skb() fail.

(As I said, these observations are the result of a relatively shallow examination of the Linux kernel code, so anyone who is more familiar with Linux, please correct me if you believe that I have overlooked or misunderstood something in making them)


Unfortunately, #1 by itself doesn't do anything to help applications like NFR which are interested in seeing *all* packets on a network in most cases. (i.e. it doesn't matter how good the filter implementation is if you are not filtering ;) As an example: there will likely be a marked performance increase with an LSF Linux kernel vs. a non-LSF Linux kernel when you do something like `tcpdump host` but no performance increase when you just do `tcpdump`.

Contrast #2 with BPF, in which case a single call to read() can yield up to 512K bytes of packet data (or more if you further increase the buffer sizes.) This means that compared to a *BSD kernel, a Linux kernel will have to context switch about 1000 times more frequently when running a sniffing application. Also note that this shortcoming affects even applications which use LSF to filter out uninteresting packets, since the packets they do get will still come up to user-space one at a time.

The operations discussed in #3 are not trivial in terms of CPU usage since they must be performed for every single packet. BPF does not have this problem because it is implemented via hooks into the device drivers.

#4 is bad for obvious reasons. A sniffer must be able to report how many packets *it* (not just the interface or abstractions below it) dropped.

I don't know what policies the Linux development community has regarding what gets added/changed when, but I imagine that the changes required to fix #2 and especially #3 above will be non-trivial enough to not be included until 2.3 (and wouldn't be available in a stable rev until 2.4 or 3.0, I guess). Since 2.2 was released less than a month ago, I think that for the foreseeable future our recommendation will continue to be to avoid Linux as a sniffing platform for performance reasons.

At this point I would like to ask that we end the Linux/*BSD debate on nfr-users.

Andrew Lambeth - Software Engineer, Network Flight Recorder, Inc.

------------------------------------------------------------------ - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to