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.
next prev parent 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 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.