Hi everyone,
I've been bitten today by bpf_fib_lookup, which I use to lookup a new
neighbor after pushing some tunnel headers in XDP. Some of the tunneled
packets have to go through a specific VLAN or they get lost - and debugging
an issue today it looks like all my generated packets have no VLAN header at
all! Digging through the kernel code, both the ipv4 and ipv6 lookup routines
end with a `return bpf_fib_set_fwd_params`, which is defined as:
static int bpf_fib_set_fwd_params(struct bpf_fib_lookup *params,
const struct neighbour *neigh,
const struct net_device *dev, u32 mtu)
{
memcpy(params->dmac, neigh->ha, ETH_ALEN);
memcpy(params->smac, dev->dev_addr, ETH_ALEN);
params->h_vlan_TCI = 0;
params->h_vlan_proto = 0;
if (mtu)
params->mtu_result = mtu; /* union with tot_len */
return 0;
}
So both vlan fields in the output struct bpf_fib_lookup are always zero. I
haven't seen this commented on anywhere, including the discussion around
introducing bpf_fib_lookup, so I assume it's an accidental oversight.
Do you have any proposals for a workaround? Right now I'm thinking of
creating a BPF map that would map ifindex->vlan, populated in the userspace
- but that assumes the output (struct bpf_fib_lookup*)->ifindex will be an
index of the vlan device and not the physical device the vlan is attached
on, which I'm not sure is the case yet.
Thanks,
Konrad Zemek
|