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.
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 have a created hardware communicating application using RS232 protocol in MFC. But as there is problem regarding voltage signal strength, i would like to shift from RS232 to TCP/IP.
Can anyone help me on this topic...?
The solution is to extend the microcontroller board with a serial device server.
Known brands are Lantronix or Moxa, but there are many other options and manufacturers. For an "embedded" solution that is integrated on your board, the "Lantronix XPort" is a typical product.
http://www.lantronix.com/device-networking/embedded-device-servers/xport.html
(I'm not affiliated with the Lantronix company.)
The Serial Device Server will connect to your RS232 on one end, and on its TCP/Ethernet side it offers usually a TCP server. It is usually configurable via network, through a built-in web interface, much like an Internet router.
Your PC application then needs to be changed as follows: Instead of opening a Windows COM port, you need to make a TCP client connection to that server, on a preconfigured TCP port. (Lantronix has 10001 as the default TCP port for this.)
But there is also special Windows driver software that lets you talk to your Serial Device Server / your microcontroller through a "virtual COM port". This is sometimes the best solution for legacy PC applications, where you cannot change the original code and have to use a Windows COM port. For a MFC application this might be a good choice.
i need only to get any voltage out from my laptop to control a relay
how to get a signal from a LAN port from any pin ?
in my laptop there is no com Port or lpt Port
also the usb port needs interfacing circuits which is not nessesary
in my simple project
thats why i choosed the LAN Port
i use (visual basic 6)
any help would much appriciated .
While such things as PoE exist, normal ports do not provide any power to external devices. The USB ports are far more likely candidates since they are designed to support powering external devices, though the amount of current supported varies by adapter/hub (most "ports" are actually internal hub ports).
I'm attempting to set up a USB serial port using:
GNAT.SERIAL_COMMUNICATIONS.
I am able to open the port but when I try to set attributes of the port I get the following exception
raised GNAT.SERIAL_COMMUNICATIONS.SERIAL_ERROR : set: cannot get comm state ( 6)
Any ideas?
Sean
Since what you are working with is not a natural Windows COM port, but an extra COM port created by a device driver, you may be interested in this question (and in particular my answer to it).
The digest is that sometimes virtual COM ports aren't accessible to programs with the normal name. Before giving up on "COM2", try "\\.\COM2"
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.