Re: kern/53562: bridge(4) breaks segmentation / TX checksum offloading

[Masanobu SAITOH <msaitoh%execsw.org@localhost>]

The following reply was made to PR kern/53562; it has been noted by GNATS.

From: Masanobu SAITOH <msaitoh%execsw.org@localhost>
To: Christoph Badura <bad%bsd.de@localhost>, gnats-bugs%netbsd.org@localhost
Cc: msaitoh%execsw.org@localhost, Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>,
 Ryota Ozaki <ozaki-r%netbsd.org@localhost>
Subject: Re: kern/53562: bridge(4) breaks segmentation / TX checksum
 offloading
Date: Sat, 6 Apr 2019 14:24:20 +0900

 On 2019/04/03 7:58, Christoph Badura wrote:
 > There is one more problem:
 > 
 > We use the same bits in csum_flags to indicate both that the hardware
 > *needs to do* offloading and that the hardware *has done* offloading.
 > 
 > IIRC, this wasn't a problem when this interface was introduced, because we
 > didn't have bridge(4) yet and packets would either travel down the stack
 > from kernel to harware or up the stack from hardware to kernel only.
 > 
 > Adding bridge(4) changed that, hence the problems.
 > 
 > To finaly resolve that for good we need separate flags to indicate that
 > the hardware did offloading and what the status of that is.
 
 In current implementation, csum_flags field is cleared when a packet
 is forwarded to an outgoing (interface). The IPv{4,6} forwarding path
 and bridge do so. (If a filter function does policy routing, it's also
 be required.) If there is a unknown path which doesn't clear csum_flags,
 it should be fixed.
 
  Do you know any real use case which get this problem?
 
 To separate flags into input and output, it solves the problem,
 but I don't know it's the good solution or not.
 
 It does not directly related to the separating, I think the correct
 way is to clear flags when those are evaluated. When a packet is
 a tunneling (encapsulated) packet, the flags should be cleared when
 the outer header is checked and passed to the next input to not to
 misunderstand the input flags.
 
 > --chris
 > 
 
 
 -- 
 -----------------------------------------------
                 SAITOH Masanobu (msaitoh%execsw.org@localhost
                                  msaitoh%netbsd.org@localhost)