September 2006 - Darwin-kernel

(no subject)
by lrv711＠bellsouth.net 19 Sep '06

19 Sep '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com i have a kernel panic from updating itunes.......how do i fix it _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Networking: mbuf->m_hdr.mh_data doesn't include DLIL header?
by Andrew Gallatin 19 Sep '06

19 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Michael Smith writes: > > On Sep 19, 2006, at 10:33 AM, Bhavesh Davda wrote: > > >> Will the following heuristic work consistently? > >> > >> if (mbuf_data(*packet) != mbuf_pktdat(*packet)) { > >> // the ethernet drivers must have stripped the L2 header. Prepend it > >> } > > > > I really meant to say: > > > > if (mbuf_data(*packet) != mbuf_datastart(*packet)) { > > ... > > } > > No; it assumes that the incoming packet was always received at the > beginning of the mbuf/cluster/external buffer, and that's not a safe > assumption. > As an example, many drivers start the reception of ethernet frames 2 bytes past the beginning of the mbuf/cluster/external buffer so that the payload portions of the frame will be nicely aligned (2 + 14 = 16). Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Networking: mbuf->m_hdr.mh_data doesn't include DLIL header?
by Andrew Gallatin 19 Sep '06

19 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Bhavesh Davda writes: > The problem is that not every packet sent to my iff_input_func has the > ethernet header stripped (okay not stripped, but the mbuf_data pointer > points beyond it). I'm just curious, but aren't all packets supposed to have their link level headers stripped before they hit dlil_input_packet()? Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Networking: mbuf->m_hdr.mh_data doesn't include DLIL header?
by Michael Smith 19 Sep '06

19 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Sep 19, 2006, at 10:33 AM, Bhavesh Davda wrote: Will the following heuristic work consistently? if (mbuf_data(*packet) != mbuf_pktdat(*packet)) { // the ethernet drivers must have stripped the L2 header. Prepend it } I really meant to say: if (mbuf_data(*packet) != mbuf_datastart(*packet)) { ... } = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… No; it assumes that the incoming packet was always received at the beginning of the mbuf/cluster/external buffer, and that's not a safe assumption. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Networking: mbuf->m_hdr.mh_data doesn't include DLIL header?
by Bhavesh Davda 19 Sep '06

19 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NAsu9k4i1HaRkZcqBphIcqiohK4F7kKsHU7f5qKHLymYm6kuUOLtIp7bPqrNXl/3fEWkmjIRlRXM6Tx5yXDkPehbILkUeWX50ruv3UAtgeU56Daqjmf/lnbF12XMUPQ90o+3NNTwa3GTHg0P9HmoQG+uOF6iHlcUUbYdItqpqDk= Will the following heuristic work consistently? if (mbuf_data(*packet) != mbuf_pktdat(*packet)) { // the ethernet drivers must have stripped the L2 header. Prepend it } I really meant to say: if (mbuf_data(*packet) != mbuf_datastart(*packet)) { ... } Sorry. -Bhavesh _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Networking: mbuf->m_hdr.mh_data doesn't include DLIL header?
by Bhavesh Davda 19 Sep '06

19 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nH+j8S0cxQjiELAYP46LqSKHUGpg+6ycNUMLsEH5VL3+TOXQjIsj5SQr0Xpnpy7ma6UEwP/RK3Oy2Jn9HJ0FCqhYDBoVde13ebxVQrJMSBvtDHhzfRJBmTAF6i4OyX7m2Y1ZZEzRBZt+l5jhwfq1bQvoO7I3Ok4Rv2Y6EEm+3Ko= I tried this approach, and it doesn't work consistently. The problem is that not every packet sent to my iff_input_func has the ethernet header stripped (okay not stripped, but the mbuf_data pointer points beyond it). As a result, now I am seeing the ethernet header repeated back to back for those packets that happened to be delivered with the ethernet header intact to my iff_input_func. I need a smarter way to figure out when the kernel is going to strip the ethernet header when delivering it to my iff_input_func. Will the following heuristic work consistently? if (mbuf_data(*packet) != mbuf_pktdat(*packet)) { // the ethernet drivers must have stripped the L2 header. Prepend it } Alternatively, I could compare mbuf_data(*packet) to *frame_ptr passed into the iff_input_func. Thanks - Bhavesh Yuck! But thanks for the code snippet, Josh! Especially because in the last few days, I've had to discover the hard way what I should really pass to mbuf_pkthdr_setheader() as the second parameter :) Thanks! I'll give this a shot too. Incidentally, my approach also "works" in the sense that now my cloned mbufs in my NKE do contain the ethernet header, but as I was afraid, mutating the input mbuf breaks the stack. I'll try your approach instead. Thanks - Bhavesh On 9/18/06, Josh Graessley <jgraessley(a)apple.com> wrote: > > The input function is allowed to make modifications. > > You will want to leave the packet in the same format you found it > before you return from the function if you're going to let the packet > continue up the stack. So something like this would work: > > errno_t myFilterInput(ifnet_t interface, protocol_family_t protocol, > mbuf_t *packet, char **frame_ptr) > { > struct ether_header *en_header = (struct ether_header*)*frame_ptr; > > /* Prepend the ethernet header */ > errno_t result = mbuf_prepend(packet, sizeof(*en_header), MBUF_WAITOK); > if (result != 0) > { > *packet = NULL; > return result; > } > *((struct ether_header*)mbuf_data(*packet)) = *en_header; > > /* Do any work you want here, including calling mbuf_dup */ > result = doSomeWork(packet); > > /* Fixup the packet to allow it to continue up the stack */ > if (result == 0 && *packet) > { > /* Fixup the original so the packet starts after the ethernet > header */ > /* This same code should be used before injecting an ethernet > packet up the stack (ifnet_input). You may also need to set the > receive interface. > mbuf_pkthdr_setheader(*packet, mbuf_data(*packet)); > mbuf_adj(*packet, sizeof(*en_header)); > } > > return result; > } > > enjoy, > -josh > > On Sep 18, 2006, at 4:17 PM, Bhavesh Davda wrote: > > > Thanks for your response, Josh. > > > > I was thinking of an alternate workaround: > > > > I'm not sure what the kpi_mbuf comment about "data" being something > > the iff_input_func can modify means, but if it indeed can modify it, I > > was going to "fix up" the m_data pointer to point to m_pktdat, before > > cloning the packet via mbuf_dup. > > > > The downside of this is that if the "data" parameter is really > > supposed to be non-mutable, then I've just broken the assumption for > > the rest of the kernel :( > > > > What do you think? > > > > Thanks > > > > - Bhavesh > > > > > > On 9/18/06, Josh Graessley <jgraessley(a)apple.com> wrote: > >> > >> The packet header field is a big disaster. > >> > >> When an ethernet driver inputs a packet it usually: > >> > >> - has the whole packet copied in to the mbuf > >> - Sets the mbuf's packet header to point to where the ethernet frame > >> starts in the mbuf > >> - uses mbuf_adj or something similar to move the start of the mbuf > >> pointer to the end of the ethernet header > >> > >> If you're doing to use mbuf_dup on one of these packets your best bet > >> is probably to: > >> - mbuf_prepend for the length of the ethernet header > >> - copy the ethernet header in to the preceeding space you just > >> created using mbuf_prepend > >> - duplicate the packet > >> - set the packet header's header field to the mbuf_data value > >> - mbuf_adj for the size of the ethernet header > >> > >> If there was one thing I could undo it would be the wacky way in > >> which this header stuff is handled. It is especially frustrating when > >> you're working with interface filters. On the outbound path, you get > >> the entire packet in the mbuf chain. On the inbound path, the > >> ethernet header is separate, in the packet header's header field. It > >> usually points to some place in the allocated space for the first > >> mbuf, but there are no guarantees this will be the case. > >> > >> -josh > >> > >> On Sep 18, 2006, at 1:46 PM, Bhavesh Davda wrote: > >> > >> > For certain packets that my iff_input_func is receiving, when I > >> looked > >> > at the entire mbuf structure received in parameter 4, I noticed > >> that > >> > the m_hdr.mh_data field offsets 14 bytes beyond the start of the > >> > ethernet frame. > >> > > >> > This is causing my mbuf_dup() cloned mbuf to not contain the 14 > >> bytes > >> > of ethernet header in my NKE. > >> > > >> > Looking in the original mbuf received in my iff_input_func, the 14 > >> > bytes of ethernet header are in the mbuf body at > >> > mbuf->M_dat.MH.MH_dat.MH_databuf[0..13]. > >> > > >> > What am I doing wrong? How do I clone the mbuf to include the DLIL > >> > header? > >> > > >> > Thanks! > >> > > >> > - Bhavesh > >> > > >> > -- > >> > Bhavesh P. Davda > >> > _______________________________________________ > >> > Do not post admin requests to the list. They will be ignored. > >> > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > >> > Help/Unsubscribe/Update your Subscription: > >> > http://lists.apple.com/mailman/options/darwin-kernel/jgraessley% > >> > 40apple.com > >> > > >> > This email sent to jgraessley(a)apple.com > >> > >> > >> > >> > > > > > > -- > > Bhavesh P. Davda > > > > -- Bhavesh P. Davda -- Bhavesh P. Davda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 9/18/06, Bhavesh Davda <bhavesh.davda(a)gmail.com> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Networking: mbuf->m_hdr.mh_data doesn't include DLIL header?
by Bhavesh Davda 19 Sep '06

19 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I6lANYMKJ7DDqzZNH6g4BslKVpuxKOMToKQjEVKrGpZr4qHEqXaKyuaQX9kQUZkd/xrUj7ARMR8iK8NdnItnY03SOb/tmD5FEm73A5I5XHV+LWaU7xPPbLOHNds0R4K4LJEuC2dsKbulgyrs8wgqvZGphYSzrwpYmuSARohcO3o= Yuck! But thanks for the code snippet, Josh! Especially because in the last few days, I've had to discover the hard way what I should really pass to mbuf_pkthdr_setheader() as the second parameter :) Thanks! I'll give this a shot too. Incidentally, my approach also "works" in the sense that now my cloned mbufs in my NKE do contain the ethernet header, but as I was afraid, mutating the input mbuf breaks the stack. I'll try your approach instead. Thanks - Bhavesh The input function is allowed to make modifications. You will want to leave the packet in the same format you found it before you return from the function if you're going to let the packet continue up the stack. So something like this would work: errno_t myFilterInput(ifnet_t interface, protocol_family_t protocol, mbuf_t *packet, char **frame_ptr) { struct ether_header *en_header = (struct ether_header*)*frame_ptr; /* Prepend the ethernet header */ errno_t result = mbuf_prepend(packet, sizeof(*en_header), MBUF_WAITOK); if (result != 0) { *packet = NULL; return result; } *((struct ether_header*)mbuf_data(*packet)) = *en_header; /* Do any work you want here, including calling mbuf_dup */ result = doSomeWork(packet); /* Fixup the packet to allow it to continue up the stack */ if (result == 0 && *packet) { /* Fixup the original so the packet starts after the ethernet header */ /* This same code should be used before injecting an ethernet packet up the stack (ifnet_input). You may also need to set the receive interface. mbuf_pkthdr_setheader(*packet, mbuf_data(*packet)); mbuf_adj(*packet, sizeof(*en_header)); } return result; } enjoy, -josh On Sep 18, 2006, at 4:17 PM, Bhavesh Davda wrote: > Thanks for your response, Josh. > > I was thinking of an alternate workaround: > > I'm not sure what the kpi_mbuf comment about "data" being something > the iff_input_func can modify means, but if it indeed can modify it, I > was going to "fix up" the m_data pointer to point to m_pktdat, before > cloning the packet via mbuf_dup. > > The downside of this is that if the "data" parameter is really > supposed to be non-mutable, then I've just broken the assumption for > the rest of the kernel :( > > What do you think? > > Thanks > > - Bhavesh > > > On 9/18/06, Josh Graessley <jgraessley(a)apple.com> wrote: >> >> The packet header field is a big disaster. >> >> When an ethernet driver inputs a packet it usually: >> >> - has the whole packet copied in to the mbuf >> - Sets the mbuf's packet header to point to where the ethernet frame >> starts in the mbuf >> - uses mbuf_adj or something similar to move the start of the mbuf >> pointer to the end of the ethernet header >> >> If you're doing to use mbuf_dup on one of these packets your best bet >> is probably to: >> - mbuf_prepend for the length of the ethernet header >> - copy the ethernet header in to the preceeding space you just >> created using mbuf_prepend >> - duplicate the packet >> - set the packet header's header field to the mbuf_data value >> - mbuf_adj for the size of the ethernet header >> >> If there was one thing I could undo it would be the wacky way in >> which this header stuff is handled. It is especially frustrating when >> you're working with interface filters. On the outbound path, you get >> the entire packet in the mbuf chain. On the inbound path, the >> ethernet header is separate, in the packet header's header field. It >> usually points to some place in the allocated space for the first >> mbuf, but there are no guarantees this will be the case. >> >> -josh >> >> On Sep 18, 2006, at 1:46 PM, Bhavesh Davda wrote: >> >> > For certain packets that my iff_input_func is receiving, when I >> looked >> > at the entire mbuf structure received in parameter 4, I noticed >> that >> > the m_hdr.mh_data field offsets 14 bytes beyond the start of the >> > ethernet frame. >> > >> > This is causing my mbuf_dup() cloned mbuf to not contain the 14 >> bytes >> > of ethernet header in my NKE. >> > >> > Looking in the original mbuf received in my iff_input_func, the 14 >> > bytes of ethernet header are in the mbuf body at >> > mbuf->M_dat.MH.MH_dat.MH_databuf[0..13]. >> > >> > What am I doing wrong? How do I clone the mbuf to include the DLIL >> > header? >> > >> > Thanks! >> > >> > - Bhavesh >> > >> > -- >> > Bhavesh P. Davda >> > _______________________________________________ >> > Do not post admin requests to the list. They will be ignored. >> > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) >> > Help/Unsubscribe/Update your Subscription: >> > http://lists.apple.com/mailman/options/darwin-kernel/jgraessley% >> > 40apple.com >> > >> > This email sent to jgraessley(a)apple.com >> >> >> >> > > > -- > Bhavesh P. Davda -- Bhavesh P. Davda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 9/18/06, Josh Graessley <jgraessley(a)apple.com> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Networking: mbuf->m_hdr.mh_data doesn't include DLIL header?
by Josh Graessley 19 Sep '06

19 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com The input function is allowed to make modifications. enjoy, -josh On Sep 18, 2006, at 4:17 PM, Bhavesh Davda wrote: Thanks for your response, Josh. I was thinking of an alternate workaround: I'm not sure what the kpi_mbuf comment about "data" being something the iff_input_func can modify means, but if it indeed can modify it, I was going to "fix up" the m_data pointer to point to m_pktdat, before cloning the packet via mbuf_dup. The downside of this is that if the "data" parameter is really supposed to be non-mutable, then I've just broken the assumption for the rest of the kernel :( What do you think? Thanks - Bhavesh The packet header field is a big disaster. When an ethernet driver inputs a packet it usually: - has the whole packet copied in to the mbuf - Sets the mbuf's packet header to point to where the ethernet frame starts in the mbuf - uses mbuf_adj or something similar to move the start of the mbuf pointer to the end of the ethernet header If you're doing to use mbuf_dup on one of these packets your best bet is probably to: - mbuf_prepend for the length of the ethernet header - copy the ethernet header in to the preceeding space you just created using mbuf_prepend - duplicate the packet - set the packet header's header field to the mbuf_data value - mbuf_adj for the size of the ethernet header If there was one thing I could undo it would be the wacky way in which this header stuff is handled. It is especially frustrating when you're working with interface filters. On the outbound path, you get the entire packet in the mbuf chain. On the inbound path, the ethernet header is separate, in the packet header's header field. It usually points to some place in the allocated space for the first mbuf, but there are no guarantees this will be the case. -josh On Sep 18, 2006, at 1:46 PM, Bhavesh Davda wrote: -- Bhavesh P. Davda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com You will want to leave the packet in the same format you found it before you return from the function if you're going to let the packet continue up the stack. So something like this would work: errno_t myFilterInput(ifnet_t interface, protocol_family_t protocol, mbuf_t *packet, char **frame_ptr) { struct ether_header *en_header = (struct ether_header*)*frame_ptr; /* Prepend the ethernet header */ errno_t result = mbuf_prepend(packet, sizeof(*en_header), MBUF_WAITOK); if (result != 0) { *packet = NULL; return result; } *((struct ether_header*)mbuf_data(*packet)) = *en_header; /* Do any work you want here, including calling mbuf_dup */ result = doSomeWork(packet); /* Fixup the packet to allow it to continue up the stack */ if (result == 0 && *packet) { /* Fixup the original so the packet starts after the ethernet header */ /* This same code should be used before injecting an ethernet packet up the stack (ifnet_input). You may also need to set the receive interface. mbuf_pkthdr_setheader(*packet, mbuf_data(*packet)); mbuf_adj(*packet, sizeof(*en_header)); } return result; } On 9/18/06, Josh Graessley <jgraessley(a)apple.com> wrote: > For certain packets that my iff_input_func is receiving, when I looked > at the entire mbuf structure received in parameter 4, I noticed that > the m_hdr.mh_data field offsets 14 bytes beyond the start of the > ethernet frame. > > This is causing my mbuf_dup() cloned mbuf to not contain the 14 bytes > of ethernet header in my NKE. > > Looking in the original mbuf received in my iff_input_func, the 14 > bytes of ethernet header are in the mbuf body at > mbuf->M_dat.MH.MH_dat.MH_databuf[0..13]. > > What am I doing wrong? How do I clone the mbuf to include the DLIL > header? > > Thanks! > > - Bhavesh > > -- > Bhavesh P. Davda > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/jgraessley% > 40apple.com > > This email sent to jgraessley(a)apple.com smime.p7s

1 0

Re: Networking: mbuf->m_hdr.mh_data doesn't include DLIL header?
by Bhavesh Davda 18 Sep '06

18 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H4JmlSyyv7p39MPONLJUkVK2EQPy2ItQHeguTWK4TaP4GEVmZ7GTk/o2aMWV8YtwSukZjmdxvydX+chrh5nYeiKFFjY2oGEOF0624B9Qduqrtz4I81e7EdCcuoifNafU4n12skjDiy3948/T2vSlOnV2egiBtJzOEYgcasY3PHo= Thanks for your response, Josh. I was thinking of an alternate workaround: I'm not sure what the kpi_mbuf comment about "data" being something the iff_input_func can modify means, but if it indeed can modify it, I was going to "fix up" the m_data pointer to point to m_pktdat, before cloning the packet via mbuf_dup. The downside of this is that if the "data" parameter is really supposed to be non-mutable, then I've just broken the assumption for the rest of the kernel :( What do you think? Thanks - Bhavesh The packet header field is a big disaster. When an ethernet driver inputs a packet it usually: - has the whole packet copied in to the mbuf - Sets the mbuf's packet header to point to where the ethernet frame starts in the mbuf - uses mbuf_adj or something similar to move the start of the mbuf pointer to the end of the ethernet header If you're doing to use mbuf_dup on one of these packets your best bet is probably to: - mbuf_prepend for the length of the ethernet header - copy the ethernet header in to the preceeding space you just created using mbuf_prepend - duplicate the packet - set the packet header's header field to the mbuf_data value - mbuf_adj for the size of the ethernet header If there was one thing I could undo it would be the wacky way in which this header stuff is handled. It is especially frustrating when you're working with interface filters. On the outbound path, you get the entire packet in the mbuf chain. On the inbound path, the ethernet header is separate, in the packet header's header field. It usually points to some place in the allocated space for the first mbuf, but there are no guarantees this will be the case. -josh On Sep 18, 2006, at 1:46 PM, Bhavesh Davda wrote: > For certain packets that my iff_input_func is receiving, when I looked > at the entire mbuf structure received in parameter 4, I noticed that > the m_hdr.mh_data field offsets 14 bytes beyond the start of the > ethernet frame. > > This is causing my mbuf_dup() cloned mbuf to not contain the 14 bytes > of ethernet header in my NKE. > > Looking in the original mbuf received in my iff_input_func, the 14 > bytes of ethernet header are in the mbuf body at > mbuf->M_dat.MH.MH_dat.MH_databuf[0..13]. > > What am I doing wrong? How do I clone the mbuf to include the DLIL > header? > > Thanks! > > - Bhavesh > > -- > Bhavesh P. Davda > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/jgraessley% > 40apple.com > > This email sent to jgraessley(a)apple.com -- Bhavesh P. Davda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 9/18/06, Josh Graessley <jgraessley(a)apple.com> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Networking: mbuf->m_hdr.mh_data doesn't include DLIL header?
by Josh Graessley 18 Sep '06

18 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com The packet header field is a big disaster. When an ethernet driver inputs a packet it usually: -josh On Sep 18, 2006, at 1:46 PM, Bhavesh Davda wrote: For certain packets that my iff_input_func is receiving, when I looked at the entire mbuf structure received in parameter 4, I noticed that the m_hdr.mh_data field offsets 14 bytes beyond the start of the ethernet frame. This is causing my mbuf_dup() cloned mbuf to not contain the 14 bytes of ethernet header in my NKE. Looking in the original mbuf received in my iff_input_func, the 14 bytes of ethernet header are in the mbuf body at mbuf->M_dat.MH.MH_dat.MH_databuf[0..13]. Thanks! - Bhavesh _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com - has the whole packet copied in to the mbuf - Sets the mbuf's packet header to point to where the ethernet frame starts in the mbuf - uses mbuf_adj or something similar to move the start of the mbuf pointer to the end of the ethernet header If you're doing to use mbuf_dup on one of these packets your best bet is probably to: - mbuf_prepend for the length of the ethernet header - copy the ethernet header in to the preceeding space you just created using mbuf_prepend - duplicate the packet - set the packet header's header field to the mbuf_data value - mbuf_adj for the size of the ethernet header If there was one thing I could undo it would be the wacky way in which this header stuff is handled. It is especially frustrating when you're working with interface filters. On the outbound path, you get the entire packet in the mbuf chain. On the inbound path, the ethernet header is separate, in the packet header's header field. It usually points to some place in the allocated space for the first mbuf, but there are no guarantees this will be the case. What am I doing wrong? How do I clone the mbuf to include the DLIL header? -- Bhavesh P. Davda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/jgraessley% 40apple.com This email sent to jgraessley(a)apple.com smime.p7s

1 0