Re: octeon: fix cnmac corrupting VLAN packets transmitted by veb
Visa Hankala <[email protected]> Fri, 17 Jul 2026 12:59:36 +0000
| Newsgroups | gmane.os.openbsd.tech |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jul 15, 2026 at 11:09:27PM +0200, Sergii Rudchenko wrote: > On 14/07/2026 13:52, Visa Hankala wrote: > > I think the initial patch could be improved a little by using > > ether_extract_headers(). This avoids adding another custom packet > > peeker, and adds IPv6 handling. > > I agree. My patch inadvertently breaks checksumming of plain, unfragmented > IPv6. > > I have considered ether_extract_header() initially, but dismissed it because > it > seemed like it is doing too much, compared to the ipoffp1 calculation code > in > base. > > Now it made me wonder what is actually supported by the hardware cnmac can > bind > to. I have hard time finding hardware specifications for Cavium processors, > but at least for CN50XX there are some caveats: > > 1. IP payload must be strictly TCP or UDP. > 2. IPv4 must have no options (IHL=5). > 3. IPv4 must not be a fragment (MF and offset must be zero). > 4. IPv6 is supported, but there must be no extension headers before TCP or > UDP > header. > > In your version of the patch we keep support for IPv6 and fulfill the > requirement #1. I hope we can commit it as a fair fix for the original > problem > with VLAN encapsulation. > > As for the rest of requirements: > > #3 seems to be fulfilled because ip_fragment() calculates checksums and > clears > the CSUM flags. > > #4 seems to be a problem to follow up on. If I read ip6_output() correctly, > it > also calculates checksums upon fragmenting but it can insert other IPv6 > extension headers (hop-by-hop, dest options, etc) prior to the payload. It > does > not happen in a basic test with nc(1), I need to investigate how to trigger > it. > Also, I wonder if we need to worry about forwarded packets. The network stack computes TCP/UDP checksums in software, and clears the checksum offload flags, before fragmentation. The network stack performs these steps before sending also if an IPv4 packet has IP options or an IPv6 packet has extension headers. (This detail was in fact inspired by cnmac(4); ip_output.c r1.305 and ip6_output.c r1.197.) Currently, network drivers should see M_TCP_CSUM_OUT or M_UDP_CSUM_OUT only if the packet is "simple" for offload and meets the above conditions. ether_extract_headers() actually checks similar things.