E14 Community recommendation for ModBus TCP client

colporteur said:

I figured someone here would have used a modbus client. Coming up zeros.

"...This also required using Modbus (TCP) within a Python script to be able to send commands..."

https://community.element14.com/challenges-projects/project14/musictime/b/blog/posts/100-year-old-player-piano-gets-an-update-music-time-via-python-and-modbus-tcp

Thanks S. I will it a try next week.

I have a programmer friend that did something simulator. He had a python script running a modbus server. I couldn't buy him enough beer to make a client:(

I figured someone here would have used a modbus client. Coming up zeros.

Hi Sean,

While it's not the best protocol for this (it's a bit "naked"! and the cloud app vendor ought to have come up with better proposals to be honest), but anyway, I was interested, because by coincidence I'm just getting going with Modbus RTU currently (RS-485 instead of TCP, some differences in the protocol). I got curious enough to try to find the user manual for the 1280 Modbus TCP card. I gave that to AI, and it generated the Python code attached below. It complained that the user manual was vague in places, which it is, so I told it to try to make a simulator that accepted a few different function codes, and then try to simulate the cloud side too). 

The screenshot shows the 1280_simulator.py file running at the left side, it just sits and waits for a connection.

On the right window, you can see the cloud_app_simulator.py file running, it makes a TCP connection to the 1280 simulator, and then tries a few function codes.

Currently the code transmits to port 127.0.0.1 and port 1502, you'd need to modify both of those to suit your needs.

Please don't ask me for modifications or tweaks, I don't know Modbus TCP nor what the AI did! : ) It might be ok but it might not. It might completely fail.

I suppose one other thing worth doing is perhaps running WireShark, and examining if it successfully decodes whatever is sent by these two simulators. I didn't try that (I've not got WireShark installed currently). I only tried running the Python code on Windows, it should work with Linux but I can't be sure.

modbus_tcp_python.zip

Well, telnet will tell you if the connection can be established, which is a first "layer" of tests.

After that, a quick search for modbus TCP lead me to this reddit with a few suggestions: https://www.reddit.com/r/PLC/comments/ncp724/modbus_tcp_computer_client/?show=original

There were a number of solutions reviewed before settling on the DMZ hosting the scale indicator. Considering all the design constraints, the solution mitigates the risk introduced by having the vendor connect and poll the device.

The goal of the post is to get a lead on a simple software tool to test the Modbus interface, not redesign the network security solution. 

My first attempt will be telnet. If it works, I'm done. Based on my understanding that you have to write in order to read the interface, I'm not confident telnet is usable. I have the programming guide for the interface, unfortunately the vendor didn't suggest a tool to make it usable to me.

My preference would be to start with a tool that someone could comment on. My experience with Modbus, is I recently learned how to spell it.  In searching the site for Modbus, there were a few posts, none currently active. A google search for Modbus Client has provided some resources for investigation on Monday. Without any leads here, I will hoe a row to one of the google hits to see what works.

In general, it is not a great approach to trust the vendor, or anyone else. You might think you trust the vendor itself, but if they get compromised, you get compromised too. You need to minimize your attack surface and trust the absolute least number of entities possible. In your setup, it sounds like there's zero reason for you to ever give access to anything for anyone, and you should be sending data to the vendor instead of them pulling data. Obviously, I don't know your exact constraints or setup, there might be a valid reason to do what you are doing, but consider this carefully.

If, if, if, if my aunt was a man she would be my uncle.

There is a trust in the vendor through a VPN tunnel. There is less trust for the scale indicator in the network.

I never thought of telnet'ing to the interface. I never think of the protocol since it was replaced by ssh. I will give it a try.

In my company, a vpn tunnel into a reverse proxy

So, to get this clear, you have set up rules that allow an computer out of your control to enter your DMZ and connect to your scale?

I find this quite dangerous security wise, I would have done it the other way around, with an internal computer talking to the scale, retrieving the values and pushing those to the cloud provider.

But if you want to test the connection, you can do it with a telnet client, provided you know the port it is listening to. I mean you won't be able to "talk" the right application layer protocol, but at least you'll see if the connection goes through.

Try first from inside the DMZ, then use a computer from outside (your phone via 4G?) to see if you can still connect. Then, you can hand over the "package" to the cloud vendor who should be able to do the same while knowing which application layer protocol to use and get the proper data out of your scale.

But once again, I find it quite dangerous to let a third party directly access a machine inside your own organization.