Re: Snaplen (git-latest) not working properly on

[Gianluca Varenni <Gianluca.Varenni () riverbed com>]

We've run some more tests, and it looks like the problem is (obviously) not just with a snaplen of 1500.

Here is what we found (using packets bigger than the snaplen):

Snaplen = 59+16n  -> caplen=58+16n
Snaplen = 60+16n  -> caplen=58+16n

The results are the same on 32- and 64-bit systems (using a 64bit libpcap on a 64bit kernel), so it's not some 32 vs 
64bit alignment issue.

@Guy: if you have some pointers/info about TPACKET_V2, maybe I can give a look at it.

Have a nice day
GV




-----Original Message-----
From: tcpdump-workers-owner () lists tcpdump org [mailto:tcpdump-workers-owner () lists tcpdump org] On Behalf Of Guy 
Harris
Sent: Sunday, January 15, 2012 6:50 PM
To: tcpdump-workers () lists tcpdump org
Subject: Re: [tcpdump-workers] Snaplen (git-latest) not working properly on linux


On Jan 15, 2012, at 6:44 PM, Gianluca Varenni wrote:

> Hi all.
>
> It looks like there is a bug in handling a snaplen of 1500 on linux (with mmap on). If I set a snaplen of 1500 and 
> receive packets > 1500 (e.g. 1514), libpcap returns only 1498 as caplen, and not 1500.
>
> Libpcap latest on git (1.3.0-PRE-GIT_2012_01_15) Linux RHEL6, kernel 
> 2.6.32-131.21.1.el6.x86_64
>
> I tested with tcpdump but I see the same issue with a custom pcap-based tool.
>
> Any ideas?

Add support for TPACKET_V3, and then nuke TPACKET_V1 and TPACKET_V2 until they glow? :-)

Probably more hell in the code that tries to figure out the buffer slot size.  Dealing with the Linux memory-mapping 
code is beginning to feel like a game of Whack-a-Mole:

        http://en.wikipedia.org/wiki/Whack-A-Mole

I'll get out my mallet and try to see if I can find that particular mole and whack it.- This is the tcpdump-workers 
list.
Visit https://cod.sandelman.ca/ to unsubscribe.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.