broken ip checksum after frag reassemble of nfs READDIR?

[Andrew Thompson]

On Wed, Apr 05, 2006 at 02:41:09PM +0200, Max Laier wrote:
> On Tuesday 04 April 2006 17:34, Daniel Hartmeier wrote:
> >
> > FreeBSD has no such part that I can find. Hence, when pf_test() returns
> > a packet with an invalid IP checksum, nothing fixes the checksum, maybe
> > except for hardware-checksumming NICs.
> >
> > Andrew, what do you suggest we do about this? Are the FreeBSD semantics
> > very clear and state that the IP checksum is pfil hook's responsibility,
> > and other pfil hooks (besides pf) are doing exactly that? I haven't used
> > the FreeBSD bridge code with other packet filters beside pf, so I simply
> > don't know.
> >
> > If pf should return only IP packets to bridge which have correct IP
> > checksums already, we can either force an unconditional recomputation in
> > pf's pfil hook function (which wraps pf_test()), or we can go further
> > down the road of doing incremental checksum fixups whenever pf changes
> > the IP header internally. Once that would be complete, OpenBSD's bridge
> > could remove the unconditional checksum recomputation, too.
> >
> > But I'm not sure what's cheaper, on average, fixing up the checksum
> > on each header change (there might be multiple changes per packet
> > processed), or simply doing it once, unconditionally, at the end.
> >
> > Right now, we're in the suboptimal middle. pf does some incremental
> > fixups, but leaves the checksum incorrect in other cases.
> 
> AFAIR, we somewhat keep track of the checksum status with csum_flags in the 
> pkthdr.  We have still some 8 bit left to use if we need them, but I think we 
> can express everything that might happen already.  If we did that pf (or any 
> other pfil consumer) could decide if it is worth to recalculate the cksum or 
> if it is something to leave to the bridge/ip_output.  If it decides to fix 
> the checksum no other action is required, if it decides not to fix the 
> checksum it sets a flag indicating that the checksum needs to be 
> recalculated.  The bridge code would then check with the outgoing interface's 
> hardware capabilities and either leave the job to the hardware or do it in 
> software itself.

Whatever the solutions is, the packet filter should either return the
packet with a correct checksum or not update it at all. Doing
incremental updates are wasted if all cases are not handled.

Personally I would like to keep the bridge doing layer2 as much as
possible so if pf can return the packet with all the layer3 processing
completed it would be great. The bridge will disable hardware txcsums on
its interfaces which pf should detect and know to fully calculate the
csum before returning.


Andrew