Andrew Gallatin writes:
> James Carlson writes:
> > The hard part is knowing which bytes are overhead and need to be
> > removed. If the sender doesn't tell you, then you're probably sunk.
>
> That's the easy part. If you set the hardware to checksum bytes
> 0..13, and it is a vlan tagged frame, you just remove bytes 14..17
That assumes that only IEEE VLAN tags are the possible header
components here.
Unless you want to be in the business of designing header detection
and handling logic for future protocols here, knowing where to start
*is* a hard problem.
Garrett D'Amore writes:
> Okay Jim. Knowing that have to subtract the VLAN tag (which is bytes 14
> thru 17 of the frame), can you take a quick look at uts/sun/io/hme.c
> line 6049, and tell me how I can adjust the value of cksum. Is it safe
> to simply subtract from cksum? (Or perhaps I need to negate the bits
> first.)
The solution is given in RFC 1624:
HC' = ~(C + (-m) + m') -- [Eqn. 3]
= ~(~HC + ~m + m')
Complement the current checksum, add the complement of the old 16-bit
value, add the new value (which will be 0000 in this case), and then
complement the result.
I'm not quite sure how to read that code, but I believe it should be
something like:
newcksum = ~oldcksum + ~hval[0] + ~hval[1];
newcksum += newcksum >> 16;
newcksum = ~newcksum;
> I can see that I'll have to add a check for ETHERTYPE_VLAN or somesuch,
> and then also check for ETHERTYPE_IP/IPV6 at bytes 18/19. Its the
> subtraction/math that I want help with. I'm *not* a cyborg, and I don't
> want to screw it up. :-)
If you're nervous, run some test cases.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
