Re: mbuf_outbound_finalize and TCP_SUM16 hardware checksum
Re: mbuf_outbound_finalize and TCP_SUM16 hardware checksum
- Subject: Re: mbuf_outbound_finalize and TCP_SUM16 hardware checksum
- From: Andrew Gallatin <email@hidden>
- Date: Tue, 3 May 2005 08:49:45 -0400 (EDT)
Anton Kuzmin writes:
> Hello,
>
> I wonder if this is a known problem (or me missing something obvious) -
> outgoing TCP packets to be sent via the built-in ethernet device (GMace)
> appear to have only MBUF_CSUM_REQ_SUM16 hardware checksum request flag
> set as seen by an output KPI interface filter, which needs to modify the
> packet and therefore calls mbuf_outbound_finalize to do the delayed
> checksums. But from the xnu source it seems that this function has no
> knowledge of this flag and does nothing to calculate the checksum.
It sounds like a bug.
>From what I understand, CSUM_TCP_SUM16 is just a special case of
CSUM_TCP. See bsd/netinet/ip_output.c. You might try just
"silently upgrading" to MBUF_CSUM_REQ_TCP when you call
mbuf_outbound_finalize().
That brings up another annoying point, which is that
mbuf_set_csum_requested() is marked KERNEL_PRIVATE, and not in the
headers (though it is callable). I discovered this yesterday
when implementing my own mbuf compression code to work around
getPhysicalSegmentsWithCoalesce() being broken.
Another bug in mbuf_outbound_finalize() (actually in
in_delayed_cksum_offset()) is that it only works on big endian hosts.
On little endian hosts, ip->ip_len must be byteswapped back into host
byte order, otherwise in_delayed_cksum_offset() will call
in_cksum_skip() with a bogus ip->ip_len. I learned this the hard way
when writing my own sort of mbuf_outbound_finalize() for a driver on
FreeBSD quite a while ago.
Drew
_______________________________________________
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