Eric Woudstra <[email protected]> wrote: > This adds the capability to evaluate 802.1ad, QinQ, PPPoE and PPPoE-in-Q > packets in the bridge filter chain.
Same comment as previous patch, this needs to explain the why, not the what. nft_do_chain_bridge() passes all packets to the interpreter, so the above statement is not correct either, you can already filter on all of these packet types. This exposes NFT_PKTINFO_L4PROTO etc, which is different than what this commit message says. I also vaguely remember I commented that this changes (breaks?) existing behaviour for a rule like "tcp dport 22 accept" which may now match e.g. a PPPoE packet. Pablo, whats your take on this? Do we need a new NFPROTO_BRIDGE expression that can munge (populate) nft_pktinfo with the l4 data? That would move this off to user policy (config) land. (or extend nft_meta_bridge, doesn't absolutely require a brand new expression). > +static inline int nft_set_bridge_pktinfo(struct nft_pktinfo *pkt, > + struct sk_buff *skb, > + const struct nf_hook_state *state, > + __be16 *proto) This is only called from one .c file and unless this gets changed later this should reside in that .c file (without inline keyword).
