Re: in_cksum_offset(), in_delayed_cksum_offset() question
Re: in_cksum_offset(), in_delayed_cksum_offset() question
- Subject: Re: in_cksum_offset(), in_delayed_cksum_offset() question
- From: "Bhavesh Davda" <email@hidden>
- Date: Tue, 23 Jan 2007 12:10:49 -0800
Date: Tue, 23 Jan 2007 10:29:37 -0800
From: Kevin Brock <email@hidden>
Subject: Re: in_cksum_offset(), in_delayed_cksum_offset() question
To: Adi Masputra <email@hidden>
Cc: Darwin Kernel <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On Jan 23, 2007, at 10:19 AM, Adi Masputra wrote:
>
> Yes, this was a long-standing bug that has been fixed recently along
> with the mbuf_outbound_finalize() byte-ordering issue. The fix should
> be available fairly soon.
It sounds like mbuf_outbound_finalize won't work at all with certain
packets (large pings, for example). I knew I had to do workarounds
for byte order problems with the function, but I hadn't realized that
it was completely broken...
To work generically with 10.4.8 and previous kernels it sounds like I
need to do my own implementation of mbuf_outbound_finalize().
Kevin Brock
email@hidden
Welcome to the club :)
I had to do the same: walk the mbuf chains and do my own TCP/UDP/IPv4
header checksum computation. I was seeing the same "freeing free mbuf"
panics after calling mbuf_outbound_finalize() on Intel Macs, and I
noticed the same pattern: only happened when the mbuf was chained with
the DLIL header in the pkthdr mbuf, and the rest of the payload split
into one or more mbufs in that chain.
--
Bhavesh P. Davda
_______________________________________________
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