Michael Lloyd

Decoding TCP/IP packet from Kepware

4 posts in this topic

I'm trying to make sense of a reply from a PLC by decoding each Hex value (hint, it's not working lol). It works great with serial MODBUS but TCP/IP is a completely different structure. 

Here's what we are seeing. I can't decide if we are getting two RX for every TX or if the event log is just splitting the response into two different lines to make it easier to view. Actually I can decide and that's what I think is going on.

7/20/2022   12:22:56.194 PM   TX        60 70 00 24 00 04 00 1C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 A1 00 04 00 89 4C 92 FF B1 00 10 00 EA 0B 03 03 20 6B 25 00 BD C6 02 00 03 00 06 00

7/20/2022   12:22:56.237 PM   RX        24 70 00 2C 00 04 00 1C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

7/20/2022   12:22:56.237 PM   RX        44 00 00 00 00 00 00 02 00 A1 00 04 00 01 00 FE 80 B1 00 18 00 EA 0B 83 00 00 00 02 00 03 00 00 00 84 1D 08 00 06 00 00 00 8A 44 01 0C

The next thing to try was to make a spreadsheet, use HEX2DEC to convert each Hex value to decimal. Like magic I expected (not really) to see the IP address of the PLC in the data. The problem is, if I understand TCP/IP packet structure right (Vegas odds on that one) the structure isn't as neat and orderly as that.

Rather than continue telling you what I don't know lets go with - Can anyone here decode this?

Share this post


Link to post
Share on other sites

Kind of answering my question, kind of not. I opened the file in Notepad ++ and it gives me a better look at data. The first Hex value is the length. After that, I'm back to trying to decode with brute force. Which doesn't work btw.

I attached the text file. Opening it in Notepad++ makes it easier to read. 

The problem we are having is the station suddenly started dropping out for no reason. Just the PLC's though. The "last good poll" for the PLC's starts lagging behind the OMNI's and can fall behind as much as 10 minutes or more. When things are good the last good poll time is the same down to the second. At the worst the PLC's both drop out and after 10 minutes of no comm the station shuts down. I'm pretty sure it's not the comm device (probably a cell modem but I've never been to this site) because the OMNI's don't drop out. There are two PLC's and two OMNI Flow computers. All are using ethernet. The OMNI Flow Computers are rock solid.

The text file is from one of the two PLC's. Watching it poll in Kepware TX/RX happens at one sec (or less) intervals which is entirely too fast for the kind of connection we have. It's not local to the server. It's probably 300 miles away from the server.

TCPIP Log.txt

Share this post


Link to post
Share on other sites

What software produced that log?  The expected boundaries for EtherNet/IP are not obvious.  Please use wireshark instead.  It will decode much of this for you.

Share this post


Link to post
Share on other sites
2 hours ago, pturmel said:

What software produced that log?  The expected boundaries for EtherNet/IP are not obvious.  Please use wireshark instead.  It will decode much of this for you.

His original post had MODBUS and the point about using Wireshark is 100% spot on.

Edited by Mark-

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now