Re: Darwin-kernel Digest, Vol 6, Issue 110
Re: Darwin-kernel Digest, Vol 6, Issue 110
- Subject: Re: Darwin-kernel Digest, Vol 6, Issue 110
- From: mm w <email@hidden>
- Date: Sun, 26 Jul 2009 10:52:34 +0200
Hello,
Ok do not assume that the header is "contiguous", so it should be
"normal", anyway this step should be handled by
in_delayed_cksum_offset in case of
if iplen > mbuf->m_len ? need confirmation
you should try:
mbuf_copydata,
then
newiplen (ip -> to host byte order)
then
mbuf_copyback
then finalize
whatever here, I do need to test, let me know if that's fixed your issue.
Best,
On Sun, Jul 26, 2009 at 5:50 AM, Brendan Creane<email@hidden> wrote:
>> network byte-order? can you give a snap code? do you copy mbuf?
>
> No, not network byte-order -- the packets are always off by either 4
> or 14 bytes, depending on the ifnet_hdrlen(). Most of the packets are
> fine. At the point when I'm calling mbuf_outbound_fianlize(), I'm not
> copying the packet, this is a straight forward interface output filter
> (e.g. enet_output_func()) that's just looking at the packet the
> network stack is passing in.
>
> It looks like the packets are coming from the tun/tap interface
> (openvpn) on their way out to en0. My guess is that the tun/tap nke is
> creating udp packets that prepend the packet header without adjusting
> the ip length. My question is really whether this is correct or not --
> it seems like the 14 byte eth header or the 4 byte DLT_NULL header
> aren't part of the IP packet, but in_delayed_cksum_offset() complains
> when there's a mismatch between the mbuf length and the IP length.
>
> thanks, bcreane
>
> On Sat, Jul 25, 2009 at 12:03 PM, <email@hidden> wrote:
>>
>> Send Darwin-kernel mailing list submissions to
>> email@hidden
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.apple.com/mailman/listinfo/darwin-kernel
>> or, via email, send a message with subject or body 'help' to
>> email@hidden
>>
>> You can reach the person managing the list at
>> email@hidden
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Darwin-kernel digest..."
>>
>>
>> Today's Topics:
>>
>> 1. mbuf_outbound_finalize() reports packet length is less than
>> mbuf length (Brendan Creane)
>> 2. Re: mbuf_outbound_finalize() reports packet length is less
>> than mbuf length (mm w)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 24 Jul 2009 15:38:03 -0700
>> From: Brendan Creane <email@hidden>
>> Subject: mbuf_outbound_finalize() reports packet length is less than
>> mbuf length
>> To: email@hidden
>> Message-ID:
>> <email@hidden>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Greetings. My interface filter nke is seeing outbound AF_INET packets with
>> an ip_len that doesn't account for the protocol header. For example, for an
>> interface that expects the 14 byte eth header at the beginning of the
>> outbound packet, ip_len is 14 bytes less than the mbuf length. When I call
>> mbuf_outbound_finalize(), in_delayed_cksum_offset bails on processing the
>> packet and reports "in_delayed_cksum_offset: ip_len (XX) doesn't match
>> actual length YY." This seems to only happen for udp packets, not tcp
>> packets.
>> I'd prefer to not clutter up the system log with this message. My question
>> is whether I should do some packet verification before calling
>> mbuf_outbound_finalize, or if this is a problem either with the entity
>> creating the packet, or with in_delayed_cksum_offset().
>>
>> thanks for your time, regards
>> Brendan Creane
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.apple.com/mailman/private/darwin-kernel/attachments/20090724/fc38d38b/attachment.html
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 25 Jul 2009 14:09:44 +0200
>> From: mm w <email@hidden>
>> Subject: Re: mbuf_outbound_finalize() reports packet length is less
>> than mbuf length
>> To: email@hidden
>> Message-ID:
>> <email@hidden>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Hello,
>>
>> network byte-order? can you give a snap code? do you copy mbuf?
>>
>> > ip_len is 14 bytes less than the mbuf length
>> network byte-order? // those functions are handling swaping jobs
>> ret = mbuf_copydata(
>> *thedata,
>> theoffset,
>> sizeof (theiplen), &theiplen)
>> ...
>>
>> if (ret == 0) and theiplen ...
>> ...
>>
>> see next
>>
>> > is whether I should do some packet verification before calling
>> yes, always working with safe data is a minimum at all, whatever the area
>>
>> mbuf_outbound_finalize(
>> *thedata,
>> theprotocol,
>> ...
>>
>> ecetera
>>
>> Best,
>>
>> On Sat, Jul 25, 2009 at 12:38 AM, Brendan Creane<email@hidden> wrote:
>> > Greetings. My interface filter nke is seeing outbound AF_INET packets with
>> > an ip_len that doesn't account for the protocol header. For example, for an
>> > interface that expects the 14 byte eth header at the beginning of the
>> > outbound packet, ip_len is 14 bytes less than the mbuf length. When I call
>> > mbuf_outbound_finalize(), in_delayed_cksum_offset bails on processing the
>> > packet and reports "in_delayed_cksum_offset: ip_len (XX) doesn't match
>> > actual length YY." This seems to only happen for udp packets, not tcp
>> > packets.
>> > I'd prefer to not clutter up the system log with this message. My question
>> > is whether I should do some packet verification before calling
>> > mbuf_outbound_finalize, or if this is a problem either with the entity
>> > creating the packet, or with in_delayed_cksum_offset().
>> > thanks for your time, regards
>> > Brendan Creane
>> > _______________________________________________
>> > 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
>> >
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Darwin-kernel mailing list
>> email@hidden
>> http://lists.apple.com/mailman/listinfo/darwin-kernel
>>
>> End of Darwin-kernel Digest, Vol 6, Issue 110
>> *********************************************
> _______________________________________________
> 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
>
_______________________________________________
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