Re: nftables: bridge filter with queue to userspace

[Florian Westphal <fw@strlen.de>]

Martin Gröger <mgroeger1@web.de> wrote:
> >>Florian told me he will come up sooner or later with native queue
> >>support for nft (ie. no bridge_netfilter required anymore).
> >Argh.  I'm a moron and forgot about this.
> How does a native (indepent on bridge) queue support should work ?

Highlevel?
nft add bridge filter forward queue

But on the backend/userspace side its a good question.

For instance, where should NFQA_PAYLOAD point to?

Start of ethernet header?
Start of network header?

If the former, what should NFQA_HWADDR contain?
Should it even be present?

What about ->hw_protocol in nfqnl_msg_packet_hdr ?

We also should definitely present VLAN headers to userspace
in some way.  Standard question is if that should be extra attribute
or if we should inject the vlan header into the packet data.

I'm leaning towards:
- NFQA_PAYLOAD starts at beginning of ethernet header
- nfqnl_msg_packet_hdr->hw_protocol is set to skb->protocol OR
  skb->vlan_proto in offload case (even though this information is
  redundant since its also present in the ethernet header ...)
- NFQA_PAYLOAD maintains illusion of disabled/non-existant VLAN hw
offload, i.e. we insert it into NFQA_PAYLOAD between mac and network
header.
- 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.