Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: "Martin Gröger" <mgroeger1@web.de>
Cc: Florian Westphal <fw@strlen.de>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	netfilter@vger.kernel.org, bernhard.thaler@wvnet.at
Subject: Re: nftables: bridge filter with queue to userspace
Date: Fri, 30 Oct 2015 22:27:03 +0100	[thread overview]
Message-ID: <20151030212703.GC3461@breakpoint.cc> (raw)
In-Reply-To: <5633D164.2010400@web.de>

Martin Gröger <mgroeger1@web.de> wrote:
> >- NFQA_PAYLOAD maintains illusion of disabled/non-existant VLAN hw
> >offload, i.e. we insert it into NFQA_PAYLOAD between mac and network
> >header.
> Sorry, I don't understand this. The VLAN header is (if exists) after
> the source MAC. If a paket is bridged, I would expect, that the VLAN
> header is kept unchanged. I would expect to find the VLAN header
> exactly there! Is this wrong?

Yes, there is no VLAN header, its removed (usually by hardware offloads)
and stored in meta data only.

Thats why I think we should transparently re-insert when sending
the copy to userspace.

(I.e. undo what hardware offloads did).

> >- NFQA_HWADDR attribute is not present (redundant, we have this in
> >   NFQA_PAYLOAD).
> >>>I still have the q&d hack that makes it work but no reroute (re-bridge,
> >>>cough) support, just dump-to-userspace.
> >>As far as I understand this would be sufficient for my usecase,
> >>since I want simply to inspect the packets and then decide to accept
> >>or drop them.
> >Yes, in fact I think we should just ignore reroute (bad idea) or rebridge
> >(what would be the use case of this...?)
> >
> >If someone really needs to be able to resend/relay packet they could do
> >this in userspace or just use PRE_ROUTING since thats before bridge
> >asks the FDB for the output port.
> >
> >We could add bridge_me_harder to pick another output device for queueing
> >in BRIDGE OUTPUT but I have no idea why one would want such feature.
> >
> I'm currently trying to understand the structure.
> So to add the missing parts:
> - there is no change in the nftable kernel modules necessary?

Not to nftables but to nfnetlink_queue module (and to bridge netfilter
kernel part).

> - there are changes in the nftnl library necessary?

No, unless we add extra attribute e.g. for vlan header but I'd like
to avoid it.

> - there are changes in nft necessary?

No, nft side should already work just fine.

> Only Pablo_nftables-osd-userday-2013.pdf and
> Nftables-osd-2013-developer.pdf.
> Is there somethimg more to read to get an better understanding of nftables?

Sorry, not that I know of.  Perhaps Patrick or Pablo have more
information available somewhere.

  reply	other threads:[~2015-10-30 21:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-29 21:23 nftables: bridge filter with queue to userspace Martin Gröger
2015-10-29 22:11 ` Pablo Neira Ayuso
2015-10-29 22:23   ` Florian Westphal
2015-10-30  7:16     ` Martin Gröger
2015-10-30 13:38       ` Florian Westphal
2015-10-30 20:21         ` Martin Gröger
2015-10-30 21:27           ` Florian Westphal [this message]
2015-10-31  9:02             ` Martin Gröger

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=20151030212703.GC3461@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=bernhard.thaler@wvnet.at \
    --cc=mgroeger1@web.de \
    --cc=netfilter@vger.kernel.org \
    --cc=pablo@netfilter.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox