All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: Lukas Tribus <luky-37@hotmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"John Fastabend" <john.r.fastabend@intel.com>,
	"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
	"Jiri Pirko" <jpirko@redhat.com>,
	"Ben Hutchings" <bhutchings@solarflare.com>,
	"Atzm Watanabe" <atzm@stratosphere.co.jp>,
	"Patrick McHardy" <kaber@trash.net>,
	"Jesse Gross" <jesse@nicira.com>,
	"Michael Richardson" <mcr@sandelman.ca>,
	"Ani Sinha" <ani@aristanetworks.com>
Subject: Re: tcpdump's capture filter: "vlan" doesn't match
Date: Fri, 17 Oct 2014 17:48:50 +0200	[thread overview]
Message-ID: <54413A62.9060806@redhat.com> (raw)
In-Reply-To: <DUB123-W25C5DA9BEDC92CD2524B68EDAB0@phx.gbl>

On 10/17/2014 01:25 AM, Lukas Tribus wrote:
>>> Isn't disabling rx-vlan-offloading supposed to remedy those problems?
>>
>> There were some discussions on this in the past e.g. [1]. We have
>> SKF_AD_VLAN_TAG and SKF_AD_VLAN_TAG_PRESENT for the BPF filter on
>> this, but libpcap is currently not making use of any of them.
>>
>> [1] http://thread.gmane.org/gmane.linux.network/247947
>
> Thanks for the link. I see the situation is unfortunate and although those
> new BPF filters in the kernel may fix the actual filtering problem, one
> thing seems to remain impossible: disabling all this kernel magic and
> passing the frame as-is to libpcap without interception (avoiding any
> kind of artificial header reconstruction).
>
> How is the situation with netsniff-ng anyway? Does it use vlan BPF filter
> in the kernel?

So in netsniff-ng we don't do obscure header reconstruction as it
hurts performance and it can result in incorrect reconstruction cases.

You however can define a bpf_asm program (e.g. tools/net/ in kernel
tree) and use instruction overloading for the vlan case from there.
Thus, you're not tied to the libpcap compiler which misses this.

For more details, I refer you to Documentation/networking/filter.txt .

      parent reply	other threads:[~2014-10-17 15:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-15 22:58 tcpdump's capture filter: "vlan" doesn't match Lukas Tribus
2014-10-16  6:10 ` Daniel Borkmann
2014-10-16 23:25   ` Lukas Tribus
2014-10-16 23:39     ` Ani Sinha
2014-10-17 15:48     ` Daniel Borkmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54413A62.9060806@redhat.com \
    --to=dborkman@redhat.com \
    --cc=ani@aristanetworks.com \
    --cc=atzm@stratosphere.co.jp \
    --cc=bhutchings@solarflare.com \
    --cc=jesse@nicira.com \
    --cc=john.r.fastabend@intel.com \
    --cc=jpirko@redhat.com \
    --cc=kaber@trash.net \
    --cc=luky-37@hotmail.com \
    --cc=mcr@sandelman.ca \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.