Re: HUGE packet-drop

[Guy Harris <guy () alum mit edu>]

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 <kaber () trash net>
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 <kaber () trash net>
    Signed-off-by: David S. Miller <davem () davemloft net>

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 <kaber () trash net>
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 <kaber () trash net>
    Signed-off-by: David S. Miller <davem () davemloft net>

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.