Libpcap of version 1.0.0 and greater uses mmap with kernel space ring buffer.
You may see the following comments in create_ring() function, which creates this
ring and populates it with fixed size frames:
"* So, for now, we just do this for Ethernet devices, where
* there's no met
I've actually seen a similar problem with different NIC drivers, e.g. on RHEL6
running in ESXi 4 with the vmxnet3 drivers.
http://article.gmane.org/gmane.network.tcpdump.devel/5703
GV
-Original Message-
From: tcpdump-workers-ow...@lists.tcpdump.org
[mailto:tcpdump-workers-ow...@lists.t
Hi,
Both machines are with Intel Gigabit Ethernet adapter, with different
revisions, though. Both use e100e driver.
So what you are actually saying, that NIC driver may handle it in a wrong
way? If so, what are the possible reasons?
How exactly you found out the driver ring frames size? Inserting
Also, We've seen such strange things happen on some card (broadcom) when
changing the MTU: the internal ring buffer (the one in the card not the one
in libpcap) was not handling dynamic resize properly, and reported batch of
strange things.
What's your network adapter?
-
This is the tcpdump-worker
Maybe your device is actually receiving these jumbos and the driver does
not discard them for some reason?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Hi,
I develop a Linux sniffer application , which uses libpcap 1.2.0 library.
The problem is that on some 2.6.16 and 2.4 kernel machines, which are
pretty much "usual", SOMETIMES SOME packets are captured partially, i.e.
tpacket_hdr structure tp_snaplen value is less then tp_len value. I see
this r
