• 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
Re: ip level NKE - how to trace the process that generates traffic?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ip level NKE - how to trace the process that generates traffic?


  • Subject: Re: ip level NKE - how to trace the process that generates traffic?
  • From: James J <email@hidden>
  • Date: Wed, 28 Mar 2012 21:05:37 +0200

What i meant is sf_connect_out_func() in its data parameter receives pure socket data without any ip/tcp headers. So forwarding it to an application would be diverting in ipfw's terminology. I was hoping i could give to the usermode application complete IP packets.
May i ask - were you writing a transparent proxy or some other kind of application? How did you tranfer data about connection parameters (i.e., IP, port, etc) to the usermode application?

28 марта 2012 г. 19:20 пользователь Matt Slot <email@hidden> написал:
Sorry for the sloppy terminology, I meant "divert" in the general sense. In terms of ipfw functionality, yeah, it's a "forward".

Matt


On Mar 28, 2012, at 12:00 PM, James J wrote:

> Hi Matt,
>
> Yes, I was thinking to use control socket for userland/kernel land communication, and i was thinking about using proc_selfpid().
> However, you described the diverting mechanism (ipfw divert rule) - a socket level redirect, whereas what I need is forwarding (ipfw forward rule) - working on an IP level (and redirecting whole IP packets to the proxy).
>
>
> Matt Slot <email@hidden> wrote:
> On Mar 28, 2012, at 10:38 AM, James J wrote:
> > I am writing a transparent proxy server, which is a user mode application, and i need to redirect all the packets to that application except those, that were generated by Proxy App itself (these packets need to be bypassed freely)..
> >
> > The only problem I have, is determining, whether the IP packet is generated by the Proxy Application (to which all the other packets should be redirected, in an ipfw manner).
>
> The way I solved this was to create a control socket, over which the proxy application would register with the kernel extension. From the ctl_setopt() callback, I cached the results of proc_selfpid() as well as details about the proxy's listener port. From then on, when a new outgoing connection was created, my sf_connect_out_func() would divert or allow the request based on after comparing against the caller's pid. WHen the control socket closed, I'd clear the cached pid and stop diverting requests.
>
> Matt
>


 _______________________________________________
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

References: 
 >ip level NKE - how to trace the process that generates traffic? (From: James J <email@hidden>)
 >Re: ip level NKE - how to trace the process that generates traffic? (From: Vincent Lubet <email@hidden>)
 >Re: ip level NKE - how to trace the process that generates traffic? (From: James J <email@hidden>)
 >Re: ip level NKE - how to trace the process that generates traffic? (From: James J <email@hidden>)
 >Re: ip level NKE - how to trace the process that generates traffic? (From: James J <email@hidden>)

  • Prev by Date: Re: ip level NKE - how to trace the process that generates traffic?
  • Next by Date: Re: Now URL connection delegate isn't called at all
  • Previous by thread: Re: ip level NKE - how to trace the process that generates traffic?
  • Next by thread: Participating in AuthBrokerAgent workflow from CFNetwork?
  • Index(es):
    • Date
    • Thread