Martin Gröger <mgroeger1@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
