Nate Lawson wrote:
Oleg Bulyzhin wrote:
On Mon, Feb 06, 2006 at 02:21:09PM -0800, Nate Lawson wrote:
Oleg Bulyzhin wrote:
nq = q->m_nextpkt;
q->m_nextpkt = NULL;
m->m_pkthdr.csum_flags &= q->m_pkthdr.csum_flags;
- m->m_pkthdr.csum_data += q->m_pkthdr.csum_data;
+ sum = m->m_pkthdr.csum_data + q->m_pkthdr.csum_data;
+ m->m_pkthdr.csum_data = (sum & 0xffff) + (sum >> 16);
m_cat(m, q);
}
#ifdef MAC
I'm not familiar with this code. So m->m_pkthdr.csum_data is 32
bits? Couldn't the same thing be achieved with making it 16 bits
since the add will wrap normally?
It will not work cause it's not just a trivial sum it's so called
"1's complement sum" (refer rfc1071 for details).
You're right, but aren't you missing the NOT step?
1. 2's complement sum
2. Add in carry
3. 1's complement of result (not)
Sam Leffler mentioned this comment from NetBSD would be helpful. Might
you add it to clear up misunderstandings like I had?
sys/mbuf.h has useful comments not found in the freebsd file:
/*
* record/packet header in first mbuf of chain; valid if M_PKTHDR set
*
* A note about csum_data: For the out-bound direction, the low 16 bits
* indicates the offset after the L4 header where the final L4 checksum
value
* is to be stored and the high 16 bits is the length of the L3 header (the
* start of the data to be checksumed). For the in-bound direction, it
is only
* valid if the M_CSUM_DATA flag is set. In this case, an L4 checksum
has been
* calculated by hardware, but it is up to software to perform final
* verification.
*
* Note for in-bound TCP/UDP checksums, we expect the csum_data to NOT
* be bit-wise inverted (the final step in the calculation of an IP
* checksum) -- this is so we can accumulate the checksum for fragmented
* packets during reassembly.
*/
Thanks,
--
Nate
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
