A possibility comes to mind.
Some of the Intel Gigabit Ethernet controllers support a scatter/gather
capability.
If the driver incorporated in your Linux distro enabled that capability, a
large enough packet ( > the driver buffer size) would be spread across
multiple SKBs and passed to the PF_RING driver.
(As I remember, such a change was incorporated into the Intel driver fairly
recently).
The PF_RING driver would then have to "reassemble" these packets into a
single PF_RING slot. From what I remember of my most recent reading of the
PF_RING code, I do not believe that the current PF_RING driver does this: it
just assumes that all of the packet bytes reside in the same SKB, so you get
some bytes of "real data" (Ethernet, IP and TCP headers at least) followed
by random junk.
Instead of ring_packet.c: 631 in add_skb_to_ring():
memcpy(&bucket[sizeof(struct pcap_pkthdr)],skb->data-displ,
hdr->caplen);
something like:
if (skb_is_nonlinear(skb))
skb_copy_bits(skb, -displ, &bucket[sizeof(struct pcap_pkthdr)],
hdr->caplen);
else
memcpy(&bucket[sizeof(struct pcap_pkthdr)], skb->data-displ,
hdr->caplen);
No, I do not have a patch to offer. I haven't the skills/time to devote to
it.
I do remember encountering a similar problem with these devices in a
different context.
HTH. OTOH, I could be completely off-base.
Date: Thu, 18 Jan 2007 17:15:22 -0500
From: "Matthew J. Roth" <[EMAIL PROTECTED]>
Subject: [Ntop-misc] A solution to the scrambled packets problem
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
List members,
I recently ran into the scrambled packets problem that Paul Williams
reported. At the time, my system spec was as follows:
Manufacturer: Dell Inc.
Product Name: PowerEdge 2950
Processor: 1 Intel Xeon 5160 @ 3.00GHz (Dual Core)
Memory: 4 GB
Network Card: Intel Corporation 82571EB Gigabit Ethernet Controller
Linux Distribution: Fedora Core 5 x86_64
Kernel Version: 2.6.18-1.2257.fc5
libpcap Version: 0.9.4
I tried various versions of PF_RING to no avail. Packets were being
captured, but their data was scrambled. After reviewing this list, I
noticed that the 2.6.18 kernel seemed to be a common theme. Today I
rolled back to a 2.6.17 kernel and rebuilt PF_RING from the current CVS,
and things are working fine again.
This is Fedora specific, but the source RPM I used is available at:
ftp://ftp.pbone.net/mirror/download.fedora.redhat.com/pub/fedora/linux/core/updates/5/SRPMS/kernel-2.6.17-1.2187_FC5.src.rpm
I don't know if the problem was related to changes in the vanilla 2.6.18
kernel or Fedora's patches, but if you are running Fedora or one of its
siblings I recommend trying a 2.6.17 kernel as your first
troubleshooting step. If you absolutely must run a 2.6.18 kernel, try a
vanilla one from kernel.org. The build process is slightly easier than
the Fedora way, but I can provide help if you need it.
Please respond to this post with any feedback.
Thank you,
Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer
_______________________________________________
Ntop-misc mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
