on amd64 tcp4 cksums are bad (FYI)
Ruslan Ermilov
ru at FreeBSD.org
Fri Aug 20 15:20:34 PDT 2004
On Fri, Aug 20, 2004 at 11:07:34PM +0300, Maxim Sobolev wrote:
> Andrew Gallatin wrote:
>
> >David W. Hankins writes:
> > >
> > > This is as observed via tcpdump on [client], which is what is producing
> > > the bad checksums. Obviously it doesn't cause a problem since no one
> > > listens to TCP checksums, but it's interesting. I only noticed it
> > > because I was tcpdump'ing for completely unrelated reasons, and it
> > caught
> > > my eye.
> >
> ><...>
> >
> > > Client machine is amd64, running 64-bit mode 5-current fresh as of
> > > yesterday. Network interface is e1000, so fxp. Server is also freebsd
> >
> >e1000 is actually em.
> >
> >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().
Cheers,
--
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20040821/0bbbace4/attachment.bin
More information about the freebsd-current
mailing list