• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Memory Leak Issue When Calling ipf_inject_output()
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Memory Leak Issue When Calling ipf_inject_output()


  • Subject: Memory Leak Issue When Calling ipf_inject_output()
  • From: "Jay K. Robertson" <email@hidden>
  • Date: Wed, 24 Mar 2010 16:27:31 -0400

Hello,

I am building an NKE on OS X 10.5.8 that captures packets using an IP
filter on the outbound path.  My ipf_output function is below.  This
is a simple function that receives IP packets, creates a new mbuf,
copies the contents of the old mbuf into the new mbuf, and sends it
out via ipf_inject_output().

This function works fine except for one major problem.  While the
packets appear to be sent correctly, if I send TCP packets outbound
through this function, it appears to leak large amounts of memory.
For some reason, this only happens on TCP packets--I don't see similar
behavior when sending UDP packets.  Unfortunately, I don't have
visibility into the kernel, so I can't really deduce why this is
happening.

To generate traffic, I am using iperf.  On the Mac running the NKE, I
am using the following command line:
  iperf -c (server IP) -t 60 -i 10

And, on the remote system, I am using the following command line:
  iperf -s

When I run this, the system is unable to allocate new mbufs, mbuf
tags, etc. after about 1 minute, and the system usually becomes
unusable.  I am out of ideas on how to resolve this issue.  Can
someone look at my code below and see what I could be doing wrong?
I'm not sure if I am completing all of the steps correctly for
capturing the packet, generating the checksums, injecting the packet,
etc., as the documentation is practically non-existent.

Thanks,
- Jay


static errno_t filter_out(void *cookie, mbuf_t *data, ipf_pktopts *opts)
{
    struct ip *iph = (struct ip *)mbuf_data(*data);
    u_int8_t protocol = iph->ip_p;
    int len = noths(iph->ip_len);
    unsigned char buf[1500];
    mbuf_t newdata = NULL;
    errno_t err, ret = 0;	// Accept packets by default
    int direction = 1;

    // Filters packets using mbuf_tag_find()
    if (0 == this->filter_match_tag(*data, direction)) {
	MSG_INFO("Ignoring previously processed packet\n");
	goto out;
    }

    // Selectively filter packets that we aren't interested in
    if (!filter_ipv4_filter(*data, protocol)) {
	goto out;
    }

    mbuf_outbound_finalize(*data, PF_INET, 0); // Finalize checksums
    ret = 1; // Free original packet regardless of what happens

    if (0 != (err = mbuf_copydata(*data, 0, len, buf))) {
	MSG_ERR("Unable to copy mbuf to buf, err=%d\n", err);
	goto out;
    }

    // At this point, it is intended that data will be sent to another
    // thread for deferred processing.  That thread will construct and
    // inject a new mbuf through ipf_inject_output().  For now, we
    // simulate the construction of the new mbuf.

    // Allocate the new packet
    if (0 != mbuf_allocpacket(MBUF_DONTWAIT, 1500, NULL, &newdata)) {
	MSG_ERR("Unable to allocate mbuf\n");
	goto out;
    // Copy data into new mbuf
    } else if (0 != mbuf_copyback(newdata, 0, len, buf, MBUF_DONTWAIT)) {
	MSG_ERR("Unable to copy buf to mbuf\n");
	mbuf_freem(newdata);
	goto out;
    // Use mbuf_tag_allocate() to set tag so that we don't process this twice
    } else if (0 != this->filter_set_tag(newdata, direction)) {
	MSG_ERR("Unable to set tag\n");
	mbuf_freem(newdata);
	goto out;
    } else {
	mbuf_clear_csum_requested(newdata);
	if (0 != (err = ipf_inject_output(newdata, NULL, NULL))) {
	    MSG_ERR("ipf_inject_output() failed, err=%d\n", err);
	} else {
	    MSG_INFO("ipf_inject_output() succeeded\n");
	}
	// newdata is freed by ipf_inject_output() upon success or failure
    }

out:
    return ret;
}
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Prev by Date: Re: Mounting a Volume with Custom Name
  • Next by Date: Re: Macnetworkprog Digest, Vol 7, Issue 12
  • Previous by thread: Re: Mounting a Volume with Custom Name
  • Next by thread: Re: Macnetworkprog Digest, Vol 7, Issue 12
  • Index(es):
    • Date
    • Thread