How to use USB adapter from NDIS filter driver.

Hi all. Please advise me. Where can I find documentation or tutorial.
I wrote an NDIS filter driver to change the entire payload from the filter driver’s send path. Now I want to use a converter (adapter connected to USB) for modification.
For this USB adapter, I have the appropriate DLLs.
Until now, these DLLs have only been called from user mode and, accordingly, this adapter has only been used from user mode.
How can I call these DLLs and use the USB adapter from the NDIS filter driver.
Thank you.

You can’t use user-mode DLLs from kernel-mode. That’s just a simple fact. You’ll have to have a helper service in user-mode.

What kind of a “payload converter” lives in a USB device? That seems fishy.

I don’t know. That USB adapter was make here very many years ago. It is doing encryption. I just want to use that adapter(converter), plugged to USB , from driver. Until now that was used from user program. Now I want use it from driver, for encryption, instead of sending all payload to user program and using that adapter from user mode, I have only user mode DLLs for working with that adapter. Thank You.

I just asked you where I can find a tutorial for all this.

There’s not going to be a tutorial, because this is not a normal thing to do. You can find tutorials on how to write user-mode services, and you can find documents telling you how to add a back door to your filter so your service can reach it. There are performance considerations as well; you don’t want to hold up all network traffic while you communicate out to user mode.

Thank you. I’ll try to understand what you mean when you say “add a back door to your filter”.

A network filter driver cannot normally be accessed by applications. To do that, you need to create a device object, with a symbolic link to enable it to be opened from user mode.

Fine. Thank you. I already have a dispatch procedure (NdisEncryptDeviceIoControl) and I can access the driver from user mode and my driver already allows IRPs to be received and returned from the user program and I can use that adapter from the user program. Please help me to use a USB adapter (encryption converter) from kernel mode (from a driver I wrote) when I have a user mode DLL with source code already written many years ago in our office.

You cannot use your user mode dll that communicates with your usb device in kernel mode. You can implement a user mode service that communicates with your ndis filter and the usb device. You have already been told this, so I guess that answer is unacceptable.

You could theoretically open your usb device from your ndis filter and communicate with it, so if you have the source for your dll, then you might be able to re-implement that for kernel mode. This seems like a lot of work.

What you’re asking for is called an “inverted call”, because it simulates allowing the driver to call out to the application. The application submits one (or more) ioctls with a buffer to fill in. The driver puts those in a queue, so they remain pending for a very long time. When the driver needs action from the app, it pops the top request from the queue, fills in the information that is needed, and completes the request. The user-mode app takes the desired action, and resubmits the ioctl back to the driver, to be placed back in the queue.

Thanks Mr. Mark_Roddy and Tim_Roberts. I understood everythink and will try to realize all You advised. Mr. Tim_Roberts, I have realized exactly what You say. But I’m afraid that the speed of the computer will not be enough when there is a lot of traffic

Even now, while I only send traffic to the user program and return it back, without using an adapter, I already feel delays when there is a lot of traffic

I don’t doubt it one bit. That’s the price you’re going to pay . This is why most encryption solutions are in external hardware.

good, thanks

Mr. Tim_Roberts. When I said adapter, I meant external USB hardware. Thank You

What I mean is, DEDICATED hardware, not a PC peripheral.

Well.

The point is that encryption can be an offload on the nic device. That avoids the massive delays your approach is going to ensure.

Right. I mean, just think about your design. Your filter gets a packet, copies it, and completes an ioctl, causing a context shift to your helper process and a kernel-to-user transition. Then, your app has to make a request to your USB device. That’s a user-to-kernel transition, followed by a trip through the USB hardware stack, and a context shift away from your process. Now, you block until the device finishes its work and sends back a response, which depends on USB delays, but is probably at least a frame time. That bubbles back up through the USB stack and causes another context shift and another kernel-to-user transition. Now, you submit the results back to your driver, causing a final user-to-kernel transition.

Do you see how that can NEVER keep up with a high-speed network? It’s just hopeless.

Thank You. Mr. Tim and Mr.Mark. Plaese ask me, if it is wrong and why, because the system gives me a heap corruption error.

In dispatch function (level 0, user thread context ):

UCHAR* pBuf = NdisAllocateMemoryWithTagPriority(pFilter->FilterHandle, length, FILTER_ALLOC_TAG, NormalPoolPriority);
NdisMoveMemory(pBuf, pFilter->BufferSend[nSend] + indexOfCurMdl, length);
PMDL pMdl = NdisAllocateMdl(pFilter->FilterHandle, pBuf, length);
MmBuildMdlForNonPagedPool(pMdl); 

and in FilterSendNetBufferListsComplete:
NdisFreeMemory(MmGetSystemAddressForMdlSafe(NET_BUFFER_FIRST_MDL(pNB), NormalPagePriority), MmGetMdlByteCount(pNB->MdlChain),0);