Hello! > The whole point of CHECKSUM_UNNECESSARY is that the hardware parses > the protocol header for us. So in this case it must calculate the > checksum for only the first 8 bytes of the payload.
I remember this place, I stalled there for a minute ages ago. He is right in his doubts, the place is confusing, device do it wrong (but they are innocent, it is just a flaw of UDP, people did not know what to do with redundant two octets in header and placed some useless thing there :-)) and if we want to be paranoid about checksum, we should really clear CHECKSUM_UNNECESSARY tag and to recheck. I preferred optimistic approach: if the checksum comes out correct, we do not really care, how device calculated it. Probably, it calculated checksum over wrong data, but got a good checksum. So what? It is not a crypto digest yet. And if device found wrong checksum, we will recalculate it anyway. I would like to add that CHECKSUM_UNNECESSARY can be used, when checksum is really wrong (on loopback), that's why it is not cleared, when trimming. CHECKSUM_HW can always fall back to CHECKSUM_NONE, but CHECKSUM_UNNECESSARY cannot. Probably, this was bad idea, but it still means that if some generic function starts to clear it, all the code using it should be reverified. Alexey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
