Is it possible open serial port which already in use?
and send data to it
Or create new one and share it for few applications?
I'm trying to avoid use of port pairs (created by windows driver)
I guess you could use an intemediate program like Hyperterminal and sendkeys to it from other apps, ao that Hyperterminal sends them from multiple sources.
Other than a workaround like that I've never heard of a port beng open in more than one program simultaneously.
Related
As show in Windows Resource Monitor:
I want to analyse network traffic of an application, but I dont know the Windows API. I used scapy or wireshark, but I don't know what data packages are this application.
So, I want to get the listening port first. But I don't know the API.
You can use GetTcpTable2() or GetExtendedTcpTable() to enumerate open TCP ports, determining which ports are listeners, and get each one's owning process.
You can use GetExtendedUdpTable() to enumerate open UDP ports and get each one's owning process.
Is it possible to detect if some serial port is being sniffed by another process running on Windows?
We have an application that receives some sensitive data that cannot be read by other people. So, before opening the serial port, we need to check if the port is being monitored.
We can use the CreateFile Windows API function to open the serial port with exclusive access rights, but if the monitor runs before our call, it can read all the communication (it opens the serial port with shared access rights, so we can open the port at the same time). To avoid this, the attempt is to check if the port is being monitored and raise an exception, warning the user. Is it possible to do this?
Port sniffing requires a filter driver, like SysInternals' PortMon utility. You are taking the wrong kind of approach to secure your application. When somebody can install a filter driver, the attacker has more than enough privileges to completely disable your app and replace it with something else of his own making. Trying to detect and prevent information loss through your app is pointless, the system itself has to be secured. A serial port is probably the first thing you'll have to lose, it is trivial to tap its wires.
Rather than lose the serial port why not encrypt your data. This assumes that both the DTE and DCE are programmable.
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.
Preliminary story
There is this program which uses the Parallel Port to synchronize with other hardware. It will set the Parallel Port output to a specified (byte) value. This works without problems when using the built-in Parallel Port of a PC. The target platforms are Windows XP to 7, all worked fine so far. Source code is in Delphi, accessible and can be modified.
How it works
In Delphi I can use the io.dll to set the value of the Parallel Port, but there are also other solutions available, like inpout32.dll or port.dll. I call something like PortOut, specify a port number and the byte value and the port is set.
What I now want to do - and where I need help
Now the change: this needs to work on a machine which has no Parallel Port built-in (not even on the mainboard). There are several options available:
use a USB to Parallel Port adapter to add a LPT port to the PC
use a PCI card which adds a LPT port to the PC
use a PCI Express card which adds a LPT port to the PC
I am currently heading for and concentrating on the easiest and cheapest possibility: a USB to Parallel Port adapter.
Main question
There seem to be differences between Parallel Port adapters which are made to connect just a printer and other adapters which seem to be more powerful. Is there really a difference? Or can I just use one of these 5$ printer-adapters, plug in my own hardware and access the port from Delphi code? Or do I need a special adapter? Has anyone experience with this? There is a related question here, but the different adapter types (if existent) are not mentioned there. This page suggests that there are indeed differences:
Contrary to all other USB parallel ports which can connect to printers only, this makes connection to most hardware.
I hope there exists a solution via USB because for this you don't have to open the PC, which means the adapter can be added on demand.
Sub-question
Do you have experience with PCI (Express) solution? I have to use one if the USB approach is not successful.
Since I've been wrestling with this very thing recently here's what I've discovered; If you mean by using IO port addressing (indicated by your reference to inpout32.dll), no. Unless your USB-parallel port driver supports full port emulation or virtualization, which most do not, this is generally not possible. If you need to directly access the port to do normal "bit-twiddling", you should get a separate Parallel port PCI-card. Most of them present themselves as normal IO at the standard address(es). I am presuming you're not planning on using the parallel port to actually communicate with a printer, right?
What is interesting is that USB-Serial adapters are much easier to use since they appear as simple virtual devices where you can merely "open" them using a simple stream; TFileStream.Create("COM1", fmOpenRead) or Windows.CreateFile("COM2", ...);
Here is some devices that purport to do full emulation of a parallel port through USB:
https://www-user.tu-chemnitz.de/~ygu/bastelecke/PC/USB2LPT/index.en.htm
I'm working on an App that talks to a serial port, and on my development machine, I'm running Vista, and that serial port is a Bluetooth connection. Occasionally, the serial port gets caught in a state where my App can no longer connect to it. In .net I get an IOException with a message reading "Element not found."
I've tried restarting the App, connecting with other Apps (a communications client like HyperTerm) but nothing helps. I can't find any more specific error message, and nothing is logged to the machine's event logs. The device manager tells me the port is "working properly."
Is there any way to find out which process and or .dll has possession of a serial port, and/or force a port closed?
If it makes any difference, my App is in C#, but structurally, it's not convenient to open and close the port with a "using" statement.
Thanks,
Andy
To the best of my knowledge you can't close a serial port that you do not have the handle to. My experience of Bluetooth serial ports is that they can end up getting mapped to different COM port numbers at connection time, and can sometimes leave bogus COM ports when disconnected. For example, I currently have no bluetooth devices connected, but if I go into device manager, I see a total of eleven COM ports listed as Bluetooth serial port The properties on each of these ports show the device as working and available, and I can usually open these ports though I get occasional failures. My work around for this is to force COM port numbers for connected deviced, through properties / advanced / COM port number. I'm not sure if the problem is driver related (IVT corp in this case) or a problem with the way Windows manages blutooth serial ports.
Sorry I couldn't be of any more help.