site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Microsoft-Entourage/10.1.4.030702.0
Look for other possibilities as well: are you always freeing the mbufs you are using?
I am not sure I know what you mean here. In my ipf_input_func (and duplicated in my ipf_output_func) I make a copy of the complete mbuf_t * data via mbuf_copydata into my own _MALLOC space. I then ctl_enqueuedata my copy and then _FREE the copy. I do not see any other mbuf_ or ctl_ methods that might come into play here. The kern_ctl_reg structure used to register a kernel control has a ctl_sendsize field that says 0 means the default size but does not say what that default is nor does it say what the size is: bytes, kBytes, ...? I want to enqueue a full IP packet so I need the ctl_sendsize to be at least 2048 bytes.
Are you sure that the queue is getting filled up?
The description of ctl_enqueuedata in sys/kern_control.h says a return code of ENOBUFS means the "queue is full or there are no free mbufs". Since there isn't an mbuf associated with the ctl_enqueuedata method I can only assume that some queue somewhere is full. There is no documentation that I know of that describes this queue or how one would free it from the KEXT and, of course, I also assume that the client application does not have access to mbufs or ctl queues or anything else in the kernel space except for what it gets from the socket via recv. It just seemed logical to me to assume that recv pulled data off the queue - especially since there is a MSG_PEEK flag for recv that implies one can look at incoming messages without removing any data. At least this is what W. R. Stevens says in UNIX Network Programming. <whine> There is not enough documentation in this area. The "Network Kernel Extensions Programming Guide" and "Kernel Programming" docs warn about how careful one needs to be when programming in the kernel and then gives you just enough information to make you dangerous. Where does a mere mortal learn about writing proper KEXTs? </whine> Thanks for the netstat tip - I will do some more debugging and see if I can't narrow this thing down some more. -Allan _______________________________________________ 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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com