Re: Getting mbuf length
Re: Getting mbuf length
- Subject: Re: Getting mbuf length
- From: Vincent Lubet <email@hidden>
- Date: Sat, 15 Nov 2008 18:01:59 -0800
On Nov 15, 2008, at 5:37 PM, Mitchell Laurren-Ring wrote:
I've got a kext that implements hooks for IP send and receive (and
installed with ipf_addv4). My send hook converts the mbuf_t to a
flat buffer using mbuf_copydata. Recently I've run into a problem
where websites with large cookies cause my code to only copy part of
the buffer. I thought that I might need to handle fragmented
packets, but the NKE Programming Guide states "IP filters only
receive reassembled packets. It is not possible to filter on packet
fragments." This was good news because it should keep my code simple
but why am I not seeing the entire packet when I copy the mbuf? I
read Working With Memory Buffers and it warns several times that one
should be careful not to overflow memory buffers when using
mbuf_copydata. What it doesn't say is how to derive the total size
of a packet given an mbuf_t. My predecessor wrote the following code:
while(pmbf)
{
DataSize += mbuf_len(pmbf);
pmbf = mbuf_next(pmbf);
}
If there is an mbuf chain, this code will handle that. It doesn't
seem to handle the more complex case of multiple packets (as defined
in NKEPG). That should be an easy bit of code to wrap around this
loop but I don't think that's my problem either. When I call
mbuf_flags on pmbf, it's always either 0x02 or 0x03. If there were a
fragmented packet, I would expect one of the higher bits to be set
(MBUF_FRAG, for example).
In summary, what is the best way to obtain the length of an mbuf
received in a packet hook function?
This method you describe should just work -- mbuf_copydata() walks
down the mbuf chain the same way the above code computes the length.
How do you know that you are not seeing the entire IP packet when you
copy the mbuf? Is the more fragments flag set in the IP header?
Vincent
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden