There is device connected to PC via 1Gbit Ethernet. WinXP/7
I want to capture data in the following way:
PC sends command to devices (initiate data acquisition)
Device is sending data to PC
User application waits for acquisition
Driver saves data in the memory
Device sends command to notify that it finished acquisition
Driver generates interrupt and user application starts reading data from driver
I have no idea how to implement that.
There is NIC driver. There is NDIS. Can user application communicate with NDIS?
Do i need to write additional driver to communicate with NDIS?
Your problem really has two parts:
How to send commands to the device
How to capture data sent from the device
The first problem has two possible solutions, depending on whether your device accepts commands encapsulated in IPv4/IPv6, or whether it requires some other low-level protocol. If the device accepts commands encapsulated in IPv4/IPv6, then just use the sockets API in your favorite programming language.
If the device requires its own non-IP protocol, then you need to add an NDIS protocol driver. There is a sample protocol driver that is included with the Windows Driver Kit; this driver essentially opens a channel that allows a usermode application to send any kind of packet. (This would be a security issue if it were deployed widely, which is why it's not a built-in feature of the operating system.) You may need to modify the protocol driver to selectively listen only for control messages from your device.
The second problem — packet capture — is already solved. You should be able to pull existing software off the shelf and integrate it in your solution. Microsoft Network Monitor has an API that you can use to easily start/stop packet capture, and iterate through the captured results. Alternatively, some people use WinPcap.
Related
I'm currently working on a Core Audio user-space HAL plugin based largely on the "NullAudio" driver example provided by Apple. (Here's a link to the example driver.)
I'm trying to figure out how a client application can communicate with the driver in order to configure it. So far I've tried using CFPreferences and CFNotificationCenter but neither work. In the latter case I can only communicate using the Darwin notification center, but its notifications cannot include any data other than the name of the notification, and consequently it's not useful for this purpose.
Given that the HAL driver is sandboxed, what method am I supposed to use to have a client application communicate with the driver?
I have a custom embedded device with a Bluetooth low energy stack. The device is advertising itself until a connection is requested, I pair and connect to it via the Bluetooth menu in Windows 10, I can read/write to my custom GATT services using the following BLE GATT functions from the Win32 API.
For my application I need to receive high frequency data using notifications on a characteristic so I enable it using the same API as stated above and receive the correct data but too slow. The default connection parameters Windows is using is not enough and I want to update them so I can receive notification events at higher frequency, but Windows API does not provide such function. I had the same problem when connection to an Android phone, and I solved it by requesting connection parameters update from the device (the slave in the connection) and the Android phone accepted it and everything worked as expected.
The only problem is when I'm trying to ask for a connection parameter update from the device when connected to a Windows master, I don't receive any response (no accept nor reject), meanwhile I still receive notification events so I know the connection is still active. And the weird thing is that if I hold the device closer to the computer's Bluetooth antenna it does receive a response and update the connection parameters like intended.
Any idea what's going on? Is it a bug in Windows stack?
The fact that holding device closer to antenna helps should be verified. Try it multiple times in a different way.
You mentioned Android, does holding device further from Android also prevent connection parameters update?
If this proves true, I'd say the device is faulty. I would compare the behavior between different devices, better if they are from different manufacturers or at least models.
I'm using the Windows Filter Platform to implement a simple firewall application.
Actually my driver is a callout driver and it can intercept 2 kinds of event: FWPM_LAYER_ALE_AUTH_CONNECT_V4 and FWPM_LAYER_ALE_AUTH_LISTEN_V4.
The driver can communicate with usermode app using inverted call model: the usermode app performs some IOCTLs, the driver save them on a queue and return a buffer when an event is triggered.
I have only a problem. I need receive a response from usermode app to the driver, so that the driver can block or permit the connection.
In past i have worked on a minifilter driver and i have used FltCreateCommunicationPort to send an event to usermode and wait a response from it ( with FltSendMessage from minifilter).
So the question: Is there something like this with WPF?
not sure if WFP provides such mechanism. But if your requirement is to share some notification events between user and kernel mode then you can use something similar as described in http://www.osronline.com/article.cfm?id=108.
WFP framework does not have any api like FltCreateCommunicationPort, you need to implement IOCTL and FwpsPendOperation0 and FwpsCompleteOperation0 WFP apis, check WDK WFP inspect sample.
Has anyone here tried connecting to the MindWave device through the COM port associated with the bluetooth device? Is it better to just connect through the Thinkgear Connector? My target language is Ruby and I was thinking of using the serial-port library.
If you connect to the serial port directly you will have to parse binary data which, actually, ThinkGear Connect socket protocol is for (all related is here) TGSP is JSON-based protocol so dealing with it in Ruby is piece of cake (below is an extract from documentation at the link above)
ThinkGear Socket Protocol (TGSP) is a JSON-based protocol for the
transmission and receipt of ThinkGear brainwave data between a client
and a server. TGSP was designed to allow languages and/or frameworks
without a standard serial port API (e.g. Flash and most scripting
languages) to easily integrate brainwave-sensing functionality through
socket APIs.
So I'd suggest you deal with TG socket protocol (I assume you don't run Ruby on an embedded device, for if you do, you will definitely need to parse data from TGAM chip by hand) rather than parse on your own, but don't forget you will have to have ThinkGear Connector software up and running everywhere you wish your code to run at.
I have built a WFP callout driver which runs in kernel mode.
Now, I'm trying to figure out how to communicate between this driver and my GUI application which runs in user-mode. Any ideas?
Exactly what I want is something like this:
The callout driver detects an incomming connection on port 4444 (This is not part of my question)
The drivers send a message to the user-mode app.
The app shows a notification to the user and asks it if we should accept/block the connection.
The user-mode app sends back the user's response to the callout driver.
Thanks!
I agree with LordDoskias. You need to create a device object and make it available to the Win32 realm. Then you can use CreateFile, ReadFile, WriteFile and the already mentioned DeviceIoControl to send requests.
In order to get notifications from the driver to the application, you can use the so-called inverted call model. You send down some IRPs (via one of the mentioned mechanisms) and do that in an asynchronous manner (or in separate threads). Then, the driver keeps them dangling until it has to notify the user mode component about something and then returns the completed IRP. Alternative methods are to set some event and have the UM request whatever the driver keeps in some kind of queue...
The gist is, there is no direct way that the driver can send some message to the user mode application.
Check this API call - DeviceIoControl
Essentially what you would do is register the driver in the object manager, then your GUI application will be able to open it and send different commands and data (there are buffers to do that) and then you have to send some custom made IOCTL code (check with the WDK manual).
If your driver is registered as a minifilter driver,
you can use minifilter communication functions, such as FltSendMessage.
Otherwise, you can use the DeviceIoControl function as it was already suggested by the other users.