Re: on amd64 tcp4 cksums are bad (FYI)

From: Ruslan Ermilov <ru_at_FreeBSD.org>
Date: Sat, 21 Aug 2004 01:55:10 +0300
On Fri, Aug 20, 2004 at 03:49:33PM -0700, Don Lewis wrote:
> On 21 Aug, Ruslan Ermilov wrote:
> > On Fri, Aug 20, 2004 at 11:07:34PM +0300, Maxim Sobolev wrote:
> >> Andrew Gallatin wrote:
> 
> >> >You're almost certainly using a driver which offloads transmit
> >> >checksums.  (both fxp and em do) Since BPF sniffs the packet before it
> >> >leaves the host, the checksum has not yet been calculated, so it looks
> >> >bad.
> >> 
> >> Is it possible to detect this situation and flag tcpdump somehow, so 
> >> that it don't trust checksum? With the widespread adoption of GigE 
> >> cards, this "problem" is likely to be more and more common.
> >> 
> > It's easy to detect using the m_pkthdr.csum_flags.  It shouldn't
> > be impossible to make a writable mbuf chain copy, and call
> > in_delayed_cksum() on a copy, before calling bpf_mtap().
> 
> >From a performance point of view, you'd probably want defer calculating
> the checksum until after the packet has passed the BPF filter, otherwise
> you'd consume an excessive amount of CPU time when sniffing for
> infrequently occurring packets on a high bandwidth network interface.
> 
Note that this is only for outgoing packets originated on this host.
Also, at least with ng_bpf(4) you have an opportunity to watch both
matching and non-matching packets, i.e., all of them.

Yes, performance will degrade if we do this, and I don't think it's a
good idea to commit this, but if someone wants it, they now know what
to do.  ;)


Cheers,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer

Received on Fri Aug 20 2004 - 20:55:15 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:07 UTC