On Thu, Aug 12, 2004 at 10:44:12AM -0400, Robert Watson wrote: > > On Thu, 12 Aug 2004, Ruslan Ermilov wrote: > > > On Thu, Aug 12, 2004 at 12:50:58PM +0100, Chris Stenton wrote: > > > I have just been doing some debugging on my 5.2.1 box and noticed that > > > outgoing tcp packets on the box are coming up with bad checksums on > > > tcpdump. I am using the nge interface. > > > > > > Here is a sample output. > > > > > > 12:44:29.458021 0:4:e2:10:60:83 0:c:6e:4e:a0:cc ip 82: > > > hawk.gnome.co.uk.ssh > kite.gnome.co.uk.2167: P [bad tcp cksum 9420!] > > > 2071:2099(28) ack 753 win 65535 (DF) [tos 0x10] (ttl 64, id 35623, len > > > 68, bad cksum 0!) > > > > > > 12:44:29.642088 0:c:6e:4e:a0:cc 0:4:e2:10:60:83 ip 60: > > > kite.gnome.co.uk.2167 > hawk.gnome.co.uk.ssh: . [tcp sum ok] 753:753(0) > > > ack 2099 win 64956 (DF) (ttl 128, id 44852, len 40) > > > > > > > > > Any ideas whats going on as the packet does not seem to be resent? > > > > > You don't have hardware checksums enabled, do you? I barely > > recall they are incompatible with bpf(4). > > They're not incompatible per se, but if you're sniffing outgoing packets > and the network interface is calculating the checksum on send, BPF will > see a version of the packet before the checksum is calculated. If tcpdump > later attempts to verify the checksum, it still won't be calculated in the > copy it sees, and will whine. It was unclear to me in the above e-mail if > this was a tcpdump of packets on the wire (say, the receiver), or on the > sender before they hit the wire. > That's what I meant exactly. Thanks for clarifying my thoughts. ;) Cheers, -- Ruslan Ermilov ru_at_FreeBSD.org FreeBSD committer
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:05 UTC