On Thu, Mar 17, 2005 at 06:29:39PM +0000, Patrick Welche wrote:
> On Thu, Mar 17, 2005 at 07:14:28PM +0100, Manuel Bouyer wrote:
> > On Thu, Mar 17, 2005 at 05:22:45PM +0000, Patrick Welche wrote:
> > > Just a "me too".. Also on ex0, with h/w csumming enabled:
> > > 
> > > 17:16:13.805723 IP (tos 0x10, ttl  64, id 41336, offset 0, flags [DF], length: 52, bad cksum 0 (->f8f0)!) 131.111.204.180.65215 > 131.111.204.183.22: . [bad tcp cksum a071 (->38f)!] ack 2560 win 33580 <nop,nop,timestamp 4600 4600>
> > > 
> > > 
> > > lots of packets with bad cksum..
> > > 
> > > However, with h/w checksums turned off, all OK according to tcpdump.
> > > (Running current/i386 of yesterday)
> > 
> > I think this is to be expected when using hardware checksum: in this case,
> > as the checksum will be computed by the adapter, the packet passed to BPF
> > didn't have the checksum updated.
> 
> Good point..

How about this:

15:35:15.825614 IP (tos 0x0, ttl  63, id 4649, offset 0, flags [none], length: 240, bad cksum 0 (->8cda)!) quartz.newn.cam.ac.uk.domain > 192.168.203.45.1072:  51958 1/5/4 time.windows.com. A time.windows.com (212)

It comes from tcpdump running on a -current box between quartz.newn and
192.168.203.45. Is the bad checksum from quartz.newn, or because the box
running tcpdump has an ex(4) with hardware checksumming? All seems to
work, so I would guess the later.. (BTW nfs seems OK for me, but the loads
are very low)

Cheers,

Patrick