Re: [PATCH v16 nf-next 3/3] netfilter: nft_chain_filter: Add bridge double vlan and pppoe

Florian Westphal <[email protected]>
Newsgroups gmane.linux.network.bridge,gmane.comp.security.firewalls.netfilter.devel,gmane.linux.network
Message-ID <[email protected]>
Eric Woudstra <[email protected]> wrote:
> >> +		return NF_ACCEPT;
> > 
> > 
> > Hmm.  I'm not sure, I think this should either drop them right away
> > OR pass them to do_chain without any changes (i.e. retain existing
> > behavior and have this be same as nft_set_pktinfo_unspec()).
> > 
> > but please wait until resend.
> > 
> > I hope to finish a larger set i've been working on by tomorrow.
> > Then I can give this a more thorough review (and also make a summary +
> > suggestion wrt. the bridge match semantics wrt.  vlan + pppoe etc.
> > 
> > My hunch is that your approach is pretty much the way to go
> > but I need to complete related homework to make sure I did not
> > miss/forget anything.
> 
> I understand. I've send this, because from v5 to v15 it moved towards
> matching in the rule, but it all started with the fact that
> nft_flow_offload_eval() uses nft_thoff().
> 
> At a bare minimum I need to address having pkt->thoff set correctly to
> implement the software bridge-fastpath.

Sorry, fail to see how thats related.

If the header is incomplete, then with your approach the packet isn't
even seen by nft_flow_offload_eval() (-> NF_ACCEPT'd).

Whats the problem with passing the skb to nft_do_chain in its
'original' form?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.