site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On 20 janv. 05, at 18:35, Stephane Sudre wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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... This email sent to site_archiver@lists.apple.com