Ignition Telnet via OPC TCP Driver

Ignition
,
1

I just happened upon a neat little tool that I thought I'd throw out there. I needed to get some detailed diagnostics on a particularly finnicky serial server that we are polling through Modbus TCP for some RTU device data. The only way to get that data was for me to open up the command prompt, telnet into the device, then run some arcane command that I could never remember just to get basic request/response statistics.

Well it turns out! you can set up a telnet connection through the TCP Driver and interact with a device just like you would in the command prompt. While I'm sure it's a MASSIVE "no-no" for stability, security, and general best practices, I think it's a reasonable solution to bringing in data from low-level devices (this was for a serial server, but you could also get diagnostics from the numerous other industrial devices that have a flimsy web/telnet/ssh server for additional info/configuration).

Basically, I set up a raw TCP driver device in Ignition, with the "writeback" setting True. Then you can subscribe to the current message in the OPC client or, more usefully, in an OPC tag. Then, you can write to the "Writeable" tag and the message will update with the response. I wrote a startup script that programmatically enables the device connection, enters "[username]\n", then "[password]\n", then the command I have to issue to get the diagnostics response. Then I parse the response into some nifty little memory tags and can display that on our device diagnostics screen. I only "poll" the tags every several seconds and it works great!

Now, this of course means that I had to hard-code the username and password in the script, but as is so often the case, it has the factory defaults still set (it's in the middle of the GOM on a PCN enclave so I don't think it's a huge risk, though many will tell me otherwise) and those are available in the manual so I don't feel too bad.

Anyway, this solved a really frustrating problem for me and maybe it'll help someone, OR! I'll get roundly corrected on why it's a horrible idea. Either way, I'm happy.

Cheers,
Seb

2

Part of the reason the U.S. Dept. of Homeland Security recommends a largely isolated production LAN is that many production systems are cobbled together from disparate technologies, and those technologies' least common denominator is often an insecure protocol. :man_shrugging:

You aren't really stretching the boundaries here--those were burned to the ground decades ago.

3

...from different eras

This is in my top 10 list of favorite parts of the job: making anything talk to anything.

2 Likes
4

I learned Python handrolling a telnet/VT220 "server" to encapsulate little bits and bobs of business logic accessible to the guys driving forklifts in the warehouse I worked at. It's fun to have protocols you can actually see working and have a halfway chance of directly understanding.

3 Likes
5

Yea, I got spoiled early on with relatively "sleeker" modern Ethernet/IP, Profinet IRT, OPC UA, MQTT, etc. based systems, and I've been having to roll up my sleeves on getting some of these other systems to talk to each other recently. As hacky as this telnet-lite solution might be for production use, it's pretty fun having to manipulate things at a low level.

6

Haha yea, like we've done some DoD consulting and it's so difficult to get some cybersecurity departments to understand how innately insecure some ICS stuff is by nature. At one point, we were asked if a CNC machine from the 90's could be made to require MFA for programming changes :melting_face:.

2 Likes