Re: Interface layer level and packets
Re: Interface layer level and packets
- Subject: Re: Interface layer level and packets
- From: Joshua Graessley <email@hidden>
- Date: Fri, 21 Jan 2005 11:32:23 -0800
Be very careful when implementing packet fragment reassembly. It is
possible for malicious hosts to fill up all of the buffers in the
kernel if the fragment reassembly code doesn't set some limits. The
darwin kernel contains some limitations.
-josh
On Jan 21, 2005, at 2:07 AM, Stephane Sudre wrote:
On 20 janv. 05, at 18:35, Stephane Sudre wrote:
I'm seeing something I'm sure it's possible to deal with but haven't
find the solution yet.
I am at the interface level. I'm dealing with an incoming Ethernet
"frame" (one buffer with a ether_header at is beginning). The buffer
is within a mbuf chain.
The IP header is indicating that the IP packet is 44 bytes long and
the IP header is 20 bytes long (no options so).
The problem I'm seeing is that the mbuf length is 46 byes after a
mbuf pull up.
So if I remove the ether_header length, I have only 32 bytes left. If
I remove the IP headers, 12 bytes left. The issue is that it's a
TCP/IP packet and so 14 bytes are at least necessary to get all the
valuable TCP information (till the TCP flags).
It's not one of the funny case described in RFC 1858 as the packet
length includes the complete TCP header.
The solution I have not found yet is: can I get the missing bytes
somehow when a mbuf pullup can't get it?
After rethinking about this, it's probably just standard packet
fragmentations. On my way to re-invent the wheel to re-unit
fragments...
_______________________________________________
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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