to move it back in to the computer itself, this would be one way of getting round the problem, the other is to simply tell WireShark to ignore this issue. With some Ethernet drivers it is possible to disable the 'off-loading' of the checksum processing i.e. As they have not yet passed through the NIC they have not yet been processed by the NIC to add the valid checksum and hence WireShark thinks there is an error. If you are running WireShark on the same computer these packets are coming from then WireShark will be seeing these packets from 'inside' the computer before the leave the computer and go out on to the network via the Ethernet NIC. However these days it is more and more common for as much processing as possible to be off-loaded to hardware, in this case the Ethernet Network Interface Controller (NIC). Header checksum: 0xbbd5 correct Good: True Bad : False with similar for the TCP and UDP checksums. Current thread: Internet Protocol: Header checksum BAD:True Rach, Darshan (Nov 24). In the 'old days' all the processing of Ethernet packets was done in software by the computer. I haven't seen this myself but can provide a theory. Anyone ever see a WireShark capture that states the Mac's checksum is bad in its outgoing IP packets? WireShark states the bad checksum "may be caused by IP checksum offload".
0 Comments
Leave a Reply. |