Eric Woudstra <[email protected]> wrote: > > 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). > > > Did you get any answer on this somewhere? I think that answer may affect > this commit, so I'll wait before sending the next version for now.
Sorry for dropping the ball on this. No, I did not. First step is to write up a summary of the current behaviour, then decide on a how-do-we-want-this-to-work and then on an how-to-get-there. I think for the second part (how-do-we-want-this-to-work) the 'greedy' approach proposed by Antoine (ip saddr 1.2.3.4 matches regardless of l2 encap) makes sense but it will be hard to get there. I will try to cook up a proposal/rfc sometime next week.
