Re: [PATCH nf-next,v2 3/3] netfilter: flowtable: initial bridge support
Pablo Neira Ayuso <[email protected]>
| Newsgroups | gmane.comp.security.firewalls.netfilter.devel |
|---|---|
| Message-ID | <alSgp8fee8DNzdrG@chamomile> |
On Sun, Jul 12, 2026 at 11:27:50AM +0200, Eric Woudstra wrote:
> On 7/10/26 12:07 PM, Pablo Neira Ayuso wrote:
[...]
> > + this_tuple->iifidx = info.indev->ifindex;
> > + for (i = info.num_encaps - 1; i >= 0; i--) {
> > + this_tuple->encap[j].id = info.encap[i].id;
> > + this_tuple->encap[j].proto = info.encap[i].proto;
> > + j++;
> > + }
> > + this_tuple->encap_num = info.num_encaps;
nft_dev_fill_bridge_path() is called with indev for dir, but
dev_fill_forward() obtains the list of devices from indev. This reverse
iteration gives us the expected encapsulation before such list of
devices for this direction in the ingress path.
> Until here, this_tuple needs to be the other_tuple.
> dev_fill_forward_path() does not traverse the bridge.
> See other comment in other patch. Also, need to copy
> the in_vlan_ingress bit.
>
> So it becomes:
>
> other_tuple->iifidx = info.indev->ifindex;
> for (i = info.num_encaps - 1; i >= 0; i--) {
> other_tuple->encap[j].id = info.encap[i].id;
> other_tuple->encap[j].proto = info.encap[i].proto;
> if (info.ingress_vlans & BIT(i))
> other_tuple->in_vlan_ingress |= BIT(j);
> j++;
> }
> other_tuple->encap_num = info.num_encaps;
I don't see how it can be this way.