Re: NKE - Socket filter - get local address problem.
Re: NKE - Socket filter - get local address problem.
- Subject: Re: NKE - Socket filter - get local address problem.
- From: Ryan McGann <email@hidden>
- Date: Mon, 4 Jun 2007 20:16:00 -0700
The way this is usually performed is to use a sysctl or a kern_ctl
socket that connects to your kernel extension. If you are unfamiliar
with kern_ctl sockets, in userspace they work just like regular
sockets; you create them like
socket( AF_INET, SOCK_DGRAM, SYSPROTO_CONTROL );
You can then write data to them, or simply call setsockopt() on it to
communicate with your kernel extension. We implemented a special
setsockopt that tells our kernel extension the userland process ID; e.g.
pid_t thePID = getpid();
setsockopt( kernsock, SYSPROTO_CONTROL, kSetControllerProcessID,
&thePID, sizeof( thePID ) );
In your kernel extension you can determine the process ID of the
process that is making the connect() using proc_selfpid(). If the
process ID returned by proc_selfpid is your userland process ID, then
you can ignore the connect() request. Alternatively, you can send the
local port number down using the setsockopt.
Ryan
On Jun 3, 2007, at 9:36 PM, Erez Kaplan wrote:
Ryan,
My NKE kext needs to ignore redirection if request is from "my
userland application".
i.e redirect all applications accept mine.
I have full code control over "my userland application".
Erez
On Jun 3, 2007, at 11:30 PM, Ryan McGann wrote:
HOWEVER - I am unable to obtain the local address at this point.
I have used
err = sock_getsockname(so, (struct sockaddr *) &local, (int)&len);
but I keep getting <0.0.0.0> as a result.
optionally is there another call back where I can examine both
addresses and change the <to> prior to bind?
Erez,
The problem is that the kernel performs an implicit bind when the
socket is connected if no local name is assigned to the socket
already. Your NKE connect_out callback is being called when the
client application calls connect() (inside the syscall basically),
so unless the client application performs a bind() first (which is
rarely done for outbound connects) the socket will not have a
local address assigned to it. The kernel will assign one later
during the actual connect. You can obtain the local address later
inside of sf_notify, when you get a notification that the socket
has gone into the connected state, but not before (as far as I know).
In short, there is no way to both redirect the socket (which can
only be done in the connect_out callback) and use the source
ip:port. Can you explain why you need the source ip:port?
Ryan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden