In article <[EMAIL PROTECTED]>, Lars Eggert <[EMAIL PROTECTED]> wrote: > > You are running tcpdump on the system that's sending the "bad" > > packets, right? It makes perfect sense. The TCP/IP stack knows > > that the NIC is going to insert the checksums, so it doesn't bother > > calculating them itself. So BPF is handed packets in mbufs without > > any checksums. On the way out to the wire, the NIC hardware/firmware > > adds the checksums, but they don't show up in the mbufs that are being > > sent to BPF. If you run tcpdump on the receiving system instead, > > you'll find that the checksums seen there are valid. > > > > The same thing happens in the bge driver, because it also offloads > > checksum generation to the NIC. > > that makes total sense. I'd like to see the paragraph above in big, bold > letters in the xl(4) man page then - so far it doesn't discuss checksum > offloading at all. :-)
I believe it's a fairly recent feature in the network stack that allows some drivers to take advantage of checksum offloading. I agree it would be nice if the individual driver man pages mentioned whether the NIC did offloading. On the other hand, the false checksum errors might better be documented in bpf(4) and tcpdump(1). There are other similar artifacts. One of them is seen when transmitting very short packets. Some NICs (e.g., the Intel 8254x) automatically pad these packets to the minimum Ethernet packet size while transmitting them. If you run tcpdump on the sending system, you'll see the short packets, before they are padded. If you run it on the receiving system, you'll see the padded packets. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
