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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:07 UTC