On Jan 31, 2011, at 10:56 AM, Jesper Dangaard Brouer wrote:
> M. V. <bored_to_death85 <at> yahoo.com> writes:
>
>> so, i dont know what else to do, seems like nothing works for me :-S
>> 1) does anyone have any other suggestions that may help?
>> 2) about MMAP support in Debian kernel: i installed Debian5.0.3 from
>> original
>> ISO file. does anyone know if MMAP exists in its kernel by default? how can
>> i
>> get sure about that?
>
> The easiest way to see if you are using the MMAPed version is to look in:
> /proc/net/ptype
>
> Your are using the MMAP version if the Function "tpacket_rcv" is listed (while
> you perform a tcpdump). Notice the "t" in front of "packet_rcv", if the "t" is
> missing, then you are using the old/normal version.
>
> If I remember correctly, you need at least libpcap 1.0.0 to have
> MMAP/tpacket_rcv support.
You need at least libpcap 1.0.0 to have tpacket ("turbo-packet", right?)
support in the standard libpcap. You could also get it with the Phil Wood
patches he mentioned, although that only supports memory-mapped access on
Linux, not FreeBSD - but he's using Linux, so that doesn't apply (well, unless
it's Debian GNU/kFreeBSD or whatever they're calling it :-)).
> And I think that if you compile libpcap on a Debian 5.0/lenny, you will not
> get
> MMAP support, because this Debian has to old version of the kernel headers.
> AFAICR, MMAP support got added in kernel 2.6.27 and Debian lenny runs 2.6.26.
I see code for tpacket support in the 2.4.20 source (two dot four dot twenty,
not two dot six dot anything); I think it dates back before then (perhaps
2.4.0). It requires CONFIG_PACKET_MMAP.
I don't know whether any of the kernel configuration stuff shipped with the
kernel has a notion of defaults or not; perhaps the default changed in 2.6.27,
so that you got tpacket support unless you explicitly configured it *out* of
the kernel, rather than not getting it unless you explicitly configured it
*into* the kernel. However, I think distributions can choose their own
defaults, so perhaps Debian changed the default at some point.
Looking at the 2.6.27 changelog:
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27
indicates that what *did* change in 2.6.27 was that they fixed some 64-bit
issues in tpacket (if I remember correctly when I looked at this issue, it was
a problem with 32-bit usermode code with a 64-bit kernel):
commit bbd6ef87c544d88c30e4b762b1b61ef267a7d279
Author: Patrick McHardy <[email protected]>
Date: Mon Jul 14 22:50:15 2008 -0700
packet: support extensible, 64 bit clean mmaped ring structure
The tpacket_hdr is not 64 bit clean due to use of an unsigned long
and can't be extended because the following struct sockaddr_ll needs
to be at a fixed offset.
Add support for a version 2 tpacket protocol that removes these
limitations.
Userspace can query the header size through a new getsockopt option
and change the protocol version through a setsockopt option. The
changes needed to switch to the new protocol version are:
1. replace struct tpacket_hdr by struct tpacket2_hdr
2. query header len and save
3. set protocol version to 2
- set up ring as usual
4. for getting the sockaddr_ll, use (void *)hdr + TPACKET_ALIGN(hdrlen)
instead of (void *)hdr + TPACKET_ALIGN(sizeof(struct tpacket_hdr))
Steps 2 and 4 can be omitted if the struct sockaddr_ll isn't needed.
Signed-off-by: Patrick McHardy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
and made some changes to pass VLAN information to tpacket users when the
hardware strips the information from the packet (and presumably supplies it
out-of-band):
commit 393e52e33c6c26ec7db290dab803bac1bed962d4
Author: Patrick McHardy <[email protected]>
Date: Mon Jul 14 22:50:39 2008 -0700
packet: deliver VLAN TCI to userspace
Store the VLAN tag in the auxillary data/tpacket2_hdr so userspace can
properly deal with hardware VLAN tagging/stripping.
Signed-off-by: Patrick McHardy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
But, as noted, whether the Debian lenny kernel has tpacket support configured
in by default is another matter.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
