In article <44c8f13b$0$667$>,
Rahan <Rahan@Rahan_badmail.com> wrote:
>"Walter Roberson" <> a écrit dans le message de
>news:6Z5yg.244404$iF6.82334@pd7tw2no...
>> When you have checksums offloaded to your network card, then a
>> sniffer on the host sniffs the packets -before- they go to the network
>> card, and so sniffs the unadjusted checksums. The network card then
>> fixes the checksums and sends out the corrected packet.
>if what you said is true, so, i will find all packets with checksum error !!
>it's not in my case !
>i have only some packets with checksum error, not all.
When checksums are offloaded to the driver, then for any particular
protocol, the checksum field stored in the packet (the one that is
sniffed) will be either a constant or whatever trash happens to be
handy. Either way, by chance sometimes that is going to be the
correct checksum: in order for the value to *never* be right,
the drivers would have to calculate the checksum and then deliberately
put in something it knew to be wrong.
Another thing you might observe is that different protocols involve
different numbers of checksums. With checksum downloading turned on,
there may be a pattern of incorrect checksums -- e.g., it might happen
for all TCP packets but not for other packets.
>And when i disabled offloading in my NIC, i don't have network problem
>(disconnexion client, lost data... etc)
It sounds like the easiest solution is to leave checksum downloading
disabled
If the NIC is not processing checksum regeneration properly, then
it could be having other difficulties that might lead to the
bad packets never leaving the NIC. You need try snooping the
data -after- it leaves the NIC, such as by using SPAN or RSPAN
to "mirror" the switchport data over to another port for analysis.