Garrett D'Amore writes: > Andrew Gallatin wrote: > > Garrett D'Amore writes: > > > > > > Yes, but the API lacks the ability to express this distinction in the > > > capability bits. So far, I've only run into problems for hardware on > > > receive... for hme and eri, they have the ability to put a different > > > start offset on tx. But for rx, you don't know in advance if the frame > > > is tagged or not, so we just program in the offset for non-tagged > > > frames. If the frame shows up tagged, then we drop the partial > > checksum > > > data before we send the packet upstream. > > > > Why don't you just fix the checksum by "subtracting" off the last 4 > > bytes of the expanded vlan header (bytes 14..17 of the frame). > > > > I had considered that, but done it mostly because I am not entirely sure > that this is universally "safe". (This is due to ignorance on my part, > and I'd love to be better informed.) > > There are two complexities in the checksum calculation that I'm > concerned about. The first is the inclusion of carry bits. The second > is the negation (~). I'm not entirely sure after these are done, that > the operation is reversible enough to safely subtract those bytes.
I think you can safely update an internet checksum in any way you want; else none of the incremental update methods would work. I have absolutely no inuitive grasp of 16-bit 1's complement math myself (and am worried that anybody who does might actually be a cyborg :), however, I had such a cyborg in my company come up with a subtraction method which we use in this case, and it passes all our test.. Drew _______________________________________________ networking-discuss mailing list [email protected]
