Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > On Tue, Jun 18, 2019 at 11:46:13AM +0200, Florian Westphal wrote: > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > [...] > > > Could you describe this problem a bit more? Small example rule plus > > > scenario. > > > > It was what wenxu reported originally: > > > > nft add rule bridge filter forward ip protocol counter .. > > > > The rule only matches if the ip packet is contained in an ethernet frame > > without vlan tag -- and thats neither expected nor desirable. > > > > This rule works when using 'meta protocol ip' as dependency instead > > of ether type ip (what we do now), because VLAN stripping will fix/alter > > skb->protocol to the inner type when the VLAN tag gets removes. > > > > It will still fail in case there are several VLAN tags, so we might > > need another meta expression that can figure out the l3 protocol type. > > How would that new meta expression would look like? I thought about extending nft_exthdr.c for L2, i.e. take ether->type, and then advance to next vlan header (if vlan type) until it either reaches skb network offset or an unknown type (which would then be considered the last/topmost one and the one carrying the l3 protocol number).
