Re: SUM16 question
Re: SUM16 question
- Subject: Re: SUM16 question
- From: Josh Graessley <email@hidden>
- Date: Fri, 22 Jul 2005 10:12:39 -0700
Hello Chris,
The special bit tells the ethernet driver to tell the chip to perform
a checksum in hardware. The hardware has a very brain dead hardware
checksum. It requires that we stash extra information in to the
csum_value field.
I would guess that if you aren't clearing these flags, when the
packet goes out, the checksum is being calculated again in hardware
which leads to an invalid checksum or the data stashed in the
csum_value field is no longer valid after the changes you make.
With the KPIs on 10.4.x there is a function called
mbuf_finalize_packet or something like that. It should look at the
flags, calculate any checksums, then clear the flags. There was a bug
that prevented it from handling the weird apple checksum bit. That
has since been fixed.
-josh
On Jul 22, 2005, at 9:03 AM, Chris Vitale wrote:
I've got an NKE protocol filter for panther that touches ip packets
and
thus recalculates the checksums. TCP packets that travel through my
wireless card (which has no HW assist) are fine, so I believe my
routines are sound.
TCP packets over my copper gig nic have bad tcp checksums. They
become
bad after I set correct the checksum. The are still bad if I don't do
anything to the checksum. I'm pretty sure it has something to do with
SUM16 (0x1000) bit that is set in the mbuf's csum_flags. This is the
only bit set in csum_flags.
What is the secret to the "Weird Apple checksum" bit?
vitale
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden