site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com _______________________________________________ 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? I was thinking that maybe I could paste re-assembled frame fragments (not IP fragments) in case it's the explanation but I have some troubles figuring out how it could be done since I just have the ether_header (which has no information related to this) and the ip header (and the IP packet is not fragmented and does not pertain to this level anyway). This email sent to site_archiver@lists.apple.com