Listening to Serial Com Ports that are In use

Question

I'm dealing with some legacy systems that are using RS232 to communicate with peripherals. I'm not very experienced with COM interfacing. I have some code that can open and use COM ports, but it can't open ports that are used by other applications. I need to black box the packets so that we can use the same protocol for updated communications.

Is there any way to "middle man" incoming packets to an open COM port and detect what packets are being sent? I'm using .NET, but I'm open to any type of solution.

(I found this out there, but I don't think this will work for me.)

Vitrics

I think the hub4com application (from com0com) might actually do what you need. – Ginelle

Could the answer to this be updated for the year 2021? This question is now like 12 years old. – Leak

Answer 1

I've used com0com - it's great for setting up virtual com ports - which doesn't help you at all.

The COM port interface is basically a 'file read'. My application throws an exception when I try to connect to a COM port that already has another instance reading from it. I'm not sure if you could try opening it as a 'read only' instead of read-write, but it's worth a try.

You should be able to write a virtual com port that can fork off your data to a log file. Com0com is open-source, so you could use that as a starting point.

Another possible solution could be to pick up an rs232 splitter cable forks the serial signal to another serial port.

Or yet another possibility is a Serial Sniffer program (or an open source sniffer).

Or try the hub4com app from the same com0com website!

Gorse

The sniffers you suggested are essentially what I have already written. I think virtualization may be the sanest way to go, but I like the idea of splitting the line. Would I be able to capture packets to and from the device? – Vitrics

do you know where to get the code for hub4com the site has the exe but I can't see the code. – Wolfgang

com0com.cvs.sourceforge.net/viewvc/com0com/hub4com Got there via: sourceforge.net/scm/?type=cvs&group_id=129551 – Gorse

Is it true that no solution for this exists even in the year 2021 for 64-bit windows? – Leak

Yes, and I think it is unlikely to expect any different. You have two-way communication to establish a serial communication link, and you can't have two people on the other side of the connection giving different answers at the same time. That's true for any connection that has a handshake (including TCP). – Gorse

Answer 2

Is there any way to "middle man"

Yes, there are many. Strongly supported in Windows through the concept of a "filter driver". Such a driver can be inserted ahead of a driver that get I/O requests and sees everything that passes by. Normally intended to alter I/O requests but also very suitable for simply monitoring the requests. Man in the middle.

The canonical example of such a driver is the venerable SysInternals' PortMon utility. Shows you everything that an app sends and receives to/from a serial port, including configuration and data. There are many such apps, just Google "serial port filter driver" (heavy on source code samples) and "serial port monitor".

One footnote with this, you do tend to have a problem on a 64-bit version of Windows. The vast majority of these apps, including PortMon, only work on the 32-bit version. The 64-bit version only allows certified drivers to be installed, there is very little money in selling these apps to justify the expense. Beware of this when you shop.

Lamori

Answer 3

I have been down this same path. A hardware splitter is the easiest solution.

hub4com setup will involve the "Add New Hardware" wizard. If you have a lot of machines, geographically separated machines, or users who are not technically savvy and lack the permissions necessary, installation could be awkward.

If this is a legacy application, does it run in ntvdm? If so, you could run it in DosBox instead and alter the DosBox code to write to a file in addition to sending/receiving to/from the serial port. DosBox is cross platform as well.

Compotation

For the time being all I know is it runs on windows. The rest is completely black box. Unfortunately the system is in Poland and I am not. My contact is reasonable computer literate. If splitting the cable will give me the ability listen to both incoming and outgoing traffic, that sounds like the way to go. – Vitrics

The splitter should be the way to go, then. In my case I discarded that solution because we had another project where a vendor also wanted to use a splitter, and I didn't want to think about splitting it twice. – Compotation

Answer 4

You could also use TCPcom to convert the data to Ethernet packets and monitor it with Wireshark - and also broadcast it elsewhere. You then use another instance of TCPcom to forward it to any com port you like - including a virtual com port. Now you have essentially hijacked the data via Ethernet. https://sourceforge.net/projects/combytcp/?source=directory

Oller