On Fri, Mar 27, 2026 at 10:43 AM Qingfang Deng [off-list ref] wrote:

Hi, Xin Long,

On Fri, Mar 27, 2026 at 9:23 PM Xin Long [off-list ref] wrote:

quoted

On Thu, Mar 26, 2026 at 9:49 PM Qingfang Deng [off-list ref] wrote:

quoted

In my v6 patch, I set phdr->length to 0xFFFF. Is that okay?

https://lore.kernel.org/netdev/20260326081127.61229-1-dqfext@gmail.com/ (local)

I think you need to check how the PPPoE stack handles this value. If
it recalculates the actual length using skb->len when phdr->length ==
0xFFFF, then this approach might be fine.

Also, how does the PPPoE stack distinguish between 0xFFFF being the
actual payload length versus it being used as a marker to indicate a
jumbo packet (similar to BIG TCP)?

In the receive function 'pppoe_rcv()': if a skb's actual payload
length is less than phdr->length, it will be dropped; if greater than
phdr->length, it will be trimmed to match phdr->length. After that,
the phdr is popped and the skb is passed to the generic PPP layer.
There is also a fastpath in Netfilter flowtable for IPv4/IPv6 that
bypasses pppoe_rcv(): it does not check phdr->length at all, and only
relies on the length field in the network header.

In the v2 version of this patch, phdr->length is not updated in
gro_complete(), so an additional check 'skb_is_gso()' is added to the
function to avoid trimming a GRO skb. Then Richard Gobert suggested
that the length field needs to be updated, and if the updated field
matches the actual length, the 'skb_is_gso()' is not necessary, but
only if the length fits in the u16 field.

I guess you have to look back to pppoe_rcv() for this, and double check
with Richard Gobert.

The phdr->length trick for jumbo packets might also affect how tcpdump
or tshark parses PPPoE packets.