Re: [PATCH net v2] rtase: Workaround for IP fragmented UDP packet hardware bug

[David Laight]

On Tue, 9 Jun 2026 08:20:10 +0000
Justin Lai <justinlai0215@xxxxxxxxxxx> wrote:

> Simon Horman <horms@xxxxxxxxxx> wrote:
> > 
> > From: 'Simon Horman' <horms@xxxxxxxxxx>
> > 
> > This is an AI-generated review of your patch. The human sending this email has
> > considered the AI review valid, or at least plausible.
> > Full review at: https://sashiko.dev
> > ---
> > rtase: Workaround for IP fragmented UDP packet hardware bug
> > 
> > The hardware parser incorrectly interprets 319/320 in a short IP fragmented
> > UDP packet payload as standard PTP destination ports and treats the fragment
> > as a PTP packet for further parsing. Pad these packets so the transport data
> > reaches RTASE_MIN_PAD_LEN before transmitting to avoid triggering the
> > hardware issue.
> >   
> > > diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > > b/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > > index ef13109c49cff..b686b84e15fe2 100644
> > > --- a/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > > +++ b/drivers/net/ethernet/realtek/rtase/rtase_main.c  
> > 
> > [ ... ]
> >   
> > > @@ -1247,6 +1248,52 @@ static u32 rtase_tx_csum(struct sk_buff *skb,  
> > const struct net_device *dev)  
> > >       return csum_cmd;
> > >  }
> > >
> > > +static bool rtase_skb_is_udp(struct sk_buff *skb) {
> > > +     int no = skb_network_offset(skb);
> > > +     struct ipv6hdr *i6h, _i6h;
> > > +     struct iphdr *ih, _ih;
> > > +
> > > +     switch (vlan_get_protocol(skb)) {
> > > +     case htons(ETH_P_IP):
> > > +             ih = skb_header_pointer(skb, no, sizeof(_ih), &_ih);
> > > +             return ih && ih->protocol == IPPROTO_UDP;
> > > +     case htons(ETH_P_IPV6):
> > > +             i6h = skb_header_pointer(skb, no, sizeof(_i6h), &_i6h);
> > > +             return i6h && i6h->nexthdr == IPPROTO_UDP;  
> > 
> > [Severity: High]
> > Does this check fail to traverse IPv6 extension headers?
> > 
> > If an IPv6 packet contains extension headers, such as an IPv6 fragment
> > (IPPROTO_FRAGMENT), the nexthdr field will contain the extension header's
> > protocol number instead of UDP.
> > 
> > Doesn't this bypass the workaround for the exact fragmented packets it is
> > intended to fix?
> >   
> Thanks for the review.
> 
> Unlike IPv4, IPv6 does not require extension header parsing for
> this workaround. The hardware only treats IPv6 packets without
> extension headers as PTP packets for further parsing.
> 
> Therefore, IPv6 packets carrying extension headers, including
> fragments, do not enter this parsing path and are not affected
> by the hardware issue addressed by this workaround.
> 
> Skipping such packets is intentional.

I thought you said that the problem only arose with packets that are
fragmented by IPv[46], in particular short final fragments.
If your hardware checks for extension headers then doesn't that mean
that you never have a problem with IPv6 packets.

-- David

...