On 11/4/25 4:53 PM, Florian Westphal wrote:
> Eric Woudstra <[email protected]> wrote:
>> + switch (*proto) {
>> + case htons(ETH_P_PPP_SES): {
>> + struct ppp_hdr {
>> + struct pppoe_hdr hdr;
>> + __be16 proto;
>> + } *ph;
>> +
>> + if (!pskb_may_pull(skb, PPPOE_SES_HLEN))
>> + return -1;
>> + ph = (struct ppp_hdr *)(skb->data);
>> + switch (ph->proto) {
>> + case htons(PPP_IP):
>> + *proto = htons(ETH_P_IP);
>> + skb_set_network_header(skb, PPPOE_SES_HLEN);
>> + return PPPOE_SES_HLEN;
>> + case htons(PPP_IPV6):
>> + *proto = htons(ETH_P_IPV6);
>> + skb_set_network_header(skb, PPPOE_SES_HLEN);
>> + return PPPOE_SES_HLEN;
>> + }
>> + break;
>> + }
>> + case htons(ETH_P_8021Q): {
>> + struct vlan_hdr *vhdr;
>> +
>> + if (!pskb_may_pull(skb, VLAN_HLEN))
>> + return -1;
>> + vhdr = (struct vlan_hdr *)(skb->data);
>> + *proto = vhdr->h_vlan_encapsulated_proto;
>> + skb_set_network_header(skb, VLAN_HLEN);
>> + return VLAN_HLEN;
>> + }
>> + }
>> + return 0;
>> +}
>> +
>> static unsigned int
>> nft_do_chain_bridge(void *priv,
>> struct sk_buff *skb,
>> const struct nf_hook_state *state)
>> {
>> struct nft_pktinfo pkt;
>> + __be16 proto;
>> + int offset;
>>
>> - nft_set_pktinfo(&pkt, skb, state);
>> + proto = eth_hdr(skb)->h_proto;
>>
>> - switch (eth_hdr(skb)->h_proto) {
>> + offset = nft_set_bridge_pktinfo(&pkt, skb, state, &proto);
>> + if (offset < 0)
>> + return NF_ACCEPT;
>
>
> Hmm. I'm not sure, I think this should either drop them right away
> OR pass them to do_chain without any changes (i.e. retain existing
> behavior and have this be same as nft_set_pktinfo_unspec()).
>
> but please wait until resend.
>
> I hope to finish a larger set i've been working on by tomorrow.
> Then I can give this a more thorough review (and also make a summary +
> suggestion wrt. the bridge match semantics wrt. vlan + pppoe etc.
>
> My hunch is that your approach is pretty much the way to go
> but I need to complete related homework to make sure I did not
> miss/forget anything.
I understand. I've send this, because from v5 to v15 it moved towards
matching in the rule, but it all started with the fact that
nft_flow_offload_eval() uses nft_thoff().
At a bare minimum I need to address having pkt->thoff set correctly to
implement the software bridge-fastpath.
The fact that it also makes possible to match L3/L4 data in the rule is
also nice to have.
Hopefully you can take this in consideration during your review.
