How do I control the network interface on Windows? Actually, the idea is quiet simple.
Establish connect to a certain adapter on a computer.
Direct whole traffic of the adapter to this program.
Give the rights to this program what must be transfer to the adapter and what should not.
I think the program has to implement any windows network adapter interface and be registered as an adapter driver. Thus, when it wants to transfer data to real adapter, the program has to call adapter driver methods. In their turn, the methods implement the same windows network interface (or that is called in other way don't really know, I hope you get the sense), don't they?
As a result, we have a kind of inheritance here.
Before use our new driver:
windows application and windows itself
________________________ windows network interface
DRIVER of Adapter1
________________________ end of OS boundaries
Adapter 1
Use our new driver:
windows application and windows itself
________________________ windows network interface
our DRIVER
________________________ windows network interface
DRIVER of Adapter1
________________________ end of OS boundaries
Adapter 1
I believe that kind of interface exists and I hope it is realized very easy.
You will likely need to hook Windows API calls to really do this. It is possible... Start by Googling hook API and Winternals - and see if you can find their sample code.
Before Winternals was bought by Microsoft they published their code. http://technet.microsoft.com/en-us/sysinternals/bb545021
The idea is this:
You write a user-mode program which controls your hooking device
driver.
Your hooking device driver determines if network traffic on
given API calls is ok.
Driver allows normal API calls to succeed if they are.
Related
First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)
I am modifying a monitor controller for a prototype. It would be convenient to send commands to the prototype using DDC/CI. In Windows, I can't find an obvious way to send a DDC/CI command to a "display dependent device".
The Monitor Configuration API can send virtual control panel commands, but it does not give access to display dependent devices (which would have an I2C address other than 0x6e).
Nicomsoft's WinI2C/DDC product seems to give access to a display dependent device, but it is end-of-life. I would prefer not to build a dependency on an end-of-life product.
NVIDIA's NVAPI has an I2C API, but I would like a solution that also works with Intel and AMD graphics adaptors.
A solution exists for windows which respect XDDM driver display model. Windows 8 and 10 use WDDM.
In XDDM there is a windows O.S. supplied video port driver, and the hardware vendor supplies a miniport driver. When the miniport driver call's the video port driver's edid helper api (VideoPortDDCMonitorHelper), the miniport must supply 4 i2c function pointers as arguments.
In order to utilize these interfaces however you must be acting as the video port driver. So you have to write a video port lower filter driver which just passes along all the interfaces on from the windows supplied video port driver to the miniport driver. Hook the api's and export them to a usermode driver or ioctl which an application can call.
It may be possible to simply mount an instance of the miniport driver and some how get it to call VideoPortDDCMonitorHelper. But with out the help of the actual video port driver it would be difficult to get guidance on how to do that. Also you would have 2 instances of the driver running which may be against the rules for windows.
It does not appear this solution works for windows 8 and 10 because they use a different display driver model which doesn't appear to expose low level control of i2c. It is internal to the miniport driver.
In current scenario i am using RS-232 communication for operating hardware component from PC using Micro Controller in between.Whole Application is Created in MFC.
I am thinking to connect PLC for communicating hardware component to PC. So can anyone tell me how we can done this?
That depends on what hardware interface the PLC provides. If it does not use RS-232 (or ethernet) then you need an adapter. If your PC accepts plugin cards then you can probably get an adapter and driver in that form.
You need to figure out what protocol is used to communicate with the PLC e.g. COMLI, knowing that you will give you an abstract model to work with that you can use to control the hardware.
I need to create a Cocoa app that will create a virtual serial port available to other apps, meaning registered in the IO Kit Registry.
Gist of the app:
Create a virtual serial port (listed in /dev and registered with the IOKit Registry)
Initiate a tcp connection out to another computer
Proxy everything received on the virtual serial port out to the
network and vice versa.
This app will be used by third party apps that talk to serial ports on the computer, allowing for the particular serial device to be located across the network. The Cocoa and network part is no problem, I've written several apps that talk over the network. My hangup is the serial port.
I've done the test with socat/netcat/minicom to verify that it all works to proxy pty/tty traffic over the network but the tty I use doesn't show up as usable by random applications because it's not registered in the IO Kit Registry.
While I can use a pty/tty master/slave for the communication, I need this slave tty to show up to Mac applications. What would be very handy is a way to register a tty in the IO Kit Registry.
Do I really need to create a custom IOKit kext driver that gets registered at Cocoa app runtime? If so, I have a big learning curve ahead of me. Where should I start reading? Or, can I use IOKit to create a virtual serial port and register it as a usable serial port for applications without having to load any kernel extensions?
Thank you for any help you can provide,
Stateful
First of all, have you checked if you can borrow a solution from this app? It's not obvious from the website if they've managed to get their virtual serial ports fully integrated into the system.
If there is a way to do it from user space, I'm not aware of it. The user-space IOKit API generally doesn't let you create class instances, let alone new device driver classes. Maybe you can somehow otherwise persuade the Cocoa libraries to find it despite not being registered in the kernel.
I don't know if you could get away with creating a "dummy" serial port in the kernel and then move your tty into its place in /dev from your userspace daemon. Maybe that's an option.
In case you do have to do it all in the kernel:
The virtual driver itself shouldn't be too much work, at least, though it will require some time to get up to speed with kernel dev. Unfortunately, the documentation is pretty thin for serial port drivers - the key is subclassing the IOSerialDriverSync abstract class. Just about the only description I've seen is in Ole Henry Halvorsen's OSX and iOS Kernel Programming book. It also has a fragment of an example for the reading & writing operations. (disclosure: I was one of the tech reviewers for this book; I don't receive any incentives for recommending it - in this case it's literally the only documentation I know of) You can find the source for a complete serial port driver in Apple's USBCDC driver, AppleUSBCDCDMM is the class that actually represents the serial port node.
It's relatively straightforward to open a so-called "kernel control" socket in the kernel, the individual APIs are documented here; from user space you use the normal BSD socket send/recv APIs. (this is also described in the aforementioned book) Your daemon can then connect to that, and all you'd need to do is push the data between the socket and the virtual serial port device. You'll need to handle disconnect events and such correctly of course.
Still, I think this is achievable as a first kernel project for an experienced C programmer (with some C++).
I hope that helps!
So I have a bluetooth device, this device uses SPP to transfer data between the PC and itself. It connects fine through Windows as a bluetooth device. I can find it, enter the paring code and assign it to a COM port. Now I want to be able to send data through the com port using Windows API but it is refusing to do so.
I suspect that I need to setup the COMMCONFIG Structure correctly (see below)
http://msdn.microsoft.com/en-us/library/aa363188(VS.85).aspx
Unfortunately I have no idea what is the proper setting. I know SPP is supposed to emulate the RS-232 communication... so maybe I have to study up on that to figure out the right setting? Or is there some automatic way to set the COMMCONFIG structure.
I seriously doubt it. If it would be used then you'll have no chance at guessing at the custom provider data without docs from the driver author. Pay attention to the handshake signals, serial port devices routinely ignore anything sent to them when the DTR signal is turned off. And not send anything back with DTR off. A driver would emulate that. Use EscapeCommFunction() to turn them on. Also try a serial comm program like HyperTerminal or Putty to test this so you can isolate the source of the problem.
Why not use the Bluetooth sockets API? No need for troublesome (virtual) COM ports then.
If you're using managed code then see my library 32feet.NET
If using native code, use SOCKADDR_BTH with Winsock connect etc, see e.g. Bluetooth and connect (Windows) Then you can use the standard Winsock send/recv API
Ok, I found that you can use the
GetCommConfig and GetCommState functions to figure out the settings.