On Aug 28, 2012, at 1:31 PM, Jean Suisse <jean.lists@gmail.com> wrote:
Hi all,
I did set up communications between a network kernel extension and a standard cocoa user app, using control socket based on the excellent TCPLogNKE example.
The cocoa app is running from a "managed" user account, which means that the user is non admin, non staff member ; The user is not allowed to administer the computer.
The issue is that the connection is partially working. Sometimes it works, sometimes not…
Using almost exactly the same code as displayed in the TCPLogNKE example, the NKE first registers a socket control structure using
ctl_register
I say almost exactly, because I removed the flag CTL_FLAG_PRIVILEGED in order for the socket to be controlled by a classic userland app (for now).
The client cocoa app then connects to the socket using a socket(PF_SYSTEM, SOCK_DGRAM, SYSPROTO_CONTROL), and gets its data using the recv function.
What is working : If the kext sends its data (one structure) and then the cocoa app uses recv, the operation succeeds and the client gets the data. It is possible to make this work indefinitely. The NKE sends its data structure (320 octets) first, then the client cocoa app uses recv to read the data and display it. It always works.
What is NOT working :
- If the client calls recv first, and if the kext sends the data after, the cocoa client app never gets the data and stays stuck on the blocking recv call. Despite the fact that the data were correctly sent by the kext. Subsequent calls to ctl_enqueuedata from the kernel will cause the remaining space reported by ctl_getenqueuespace to decrease, proving that the data are indeed sent.
- If the NKE first sends three data structures, then the first call to recv from the client will succeed. But on the second call, it will get stuck on a blocking recv call despite the two data structures remaining in the buffer.
The things I don't understand:
- Calling recv from the client when no data are enqueued is blocking. Fine. I am even counting on it. But why would it prevent the client from ever receiving any data ?
- On the NKE side, everything goes always well. When the client is "stuck" on a recv call, ctl_enqueuedata will succeed as long as there is enough space in the buffer. Why would the client never get it ?
This is driving me mad. The worse is that I don't see any difference between my code and the TCPLogNKE example (except for the privilege flag).
Finally, I tried calling recv from the main thread of my app, as well as from the global queue. No difference (except that on the main thread, recv is of course making the app unresponsive).
When you call ctl_enqueuedata, are you passing CTL_DATA_EOR in to the flags? For an example, see bsd/net/ntstat.c in the xnu project. -josh _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com