1
\$\begingroup\$

I am having an interoperability problem between a Modbus/TCP driver from one company and a Modbus/TCP device from another.

The Modbus driver I am using seems to be able to correctly read all but four of the available registers within the device (which should bring back two results that are used in my application). I have included a screenshot below, which shows the typical request (from the Modbus driver) and the response (from the Modbus device) using Wireshark.

Is there a problem with the response and does it explain why the Modbus driver may not be picking up values for the queried registers?

I have tried another application which polls these same registers and it was able to correctly receive the expected values, which only seems to add to my dilemma . . .

Many thanks in advance.

enter image description here

\$\endgroup\$
4
  • \$\begingroup\$ Why does the response contain HTML markup, is it supposed to? Also, I think Wireshark can decode Modbus-TCP, is it working? (Maybe you'll need to enable it with right-click, decode-as, or similar.) \$\endgroup\$
    – maxy
    Feb 17, 2023 at 12:44
  • \$\begingroup\$ interestingly, that seems to change between read requests - sometimes all 00's, other times it appears random. \$\endgroup\$
    – dwp321
    Feb 17, 2023 at 12:48
  • 1
    \$\begingroup\$ Sounds like the other device is happily responding with random memory (a bug) instead of errors. Modbus has distinct function codes for single/multi register read, maybe this makes the difference between working/not working? \$\endgroup\$
    – maxy
    Feb 17, 2023 at 12:54
  • \$\begingroup\$ I'm trying not influence the outcome of the second opinion I'm seeking, but I thought the value "cb" in the response (line 0030) might be noteworthy. \$\endgroup\$
    – dwp321
    Feb 17, 2023 at 13:09

1 Answer 1

3
\$\begingroup\$

Well, it definitely looks strange to me.

I read it as

READ-HOLDING-REGISTERS(addr=0x082f, nwords=4) 
=> [0x0000, 0x736b, 0x0000, 0x0a7b]

but with lots of trash in the return.

#       / transaction id
#       |     / protocol
#       |     |     / nbytes
#       |     |     |     / unit
#       |     |     |     |  / opcode
#       |     |     |     |  |  / addr
#       |     |     |     |  |  |     / nword
#       |     |     |     |  |  |     |
        00 00 00 00 00 06 01 03 08 2f 00 04 <== from wireshark

and the result

#       / transaction id
#       |     / protocol
#       |     |     / nbytes
#       |     |     |     / unit
#       |     |     |     |  / opcode
#       |     |     |     |  |  / nbyte
#       |     |     |     |  |  |  / word 0
#       |     |     |     |  |  |  |     / word 1
#       |     |     |     |  |  |  |     |     / word 2
#       |     |     |     |  |  |  |     |     |     / word 3
#       |     |     |     |  |  |  |     |     |     |     / trash!
#       |     |     |     |  |  |  |     |     |     |     |     
        00 00 00 00 00 cb 01 03 08 00 00 73 6b 00 00 0a 7b 6f 6c 6c 69 00 00 0f e1 61  <== from Wireshark
                       ^ peculiar, expecting 0x0b          ^ peculiar

So I agree with you: the outer nbytes seems a crazy value of 0xcb, when we'd expect 8 + 3 = 0x0b. And there is a lot of random buffer coming after, which we'd expect to change according to what the device has been doing -- it's definitely a memory leak bug. But by robustness principle isn't actually a protocol error, and could be considered padding (I'll re-read the Modbus protocol for anything about padding later.)

Are those four response words correct? What are you expecting?

For Modbus/TCP you should have a 7-byte "MBAP Header" followed by the 5-byte query or (nwords * 2 + 2) bytes of response (or 2-byte error).

From MODBUS MESSAGING ON TCP/IP IMPLEMENTATION GUIDEV1.0b:

enter image description here

From MODBUS Application Protocol Specification V1.1b3: enter image description here

I've seen extraordinary bugs in Modbus implementations, my suggestion would be to try different value for nwords, different starting Modbus addresses and see if you still get your problem.

I hope that's helpful.

\$\endgroup\$
14
  • \$\begingroup\$ Hi jonathanjo, thank you for your response. Yes, despite the trash, the values in words 0 - 3 appear correct. I'll try to see if there is anything that can be done in terms of reading the registers, as suggested. I did try reading just two words, but I still saw the same problem. This particular block of 4 words are addressed much higher than any of the other Modbus registers I needed, so because of the big gap, I configured the driver to read these words separately. Trying to read the lower values and these values didn't appear to work. \$\endgroup\$
    – dwp321
    Feb 17, 2023 at 14:20
  • \$\begingroup\$ Is the client driver going wrong because of the extra 0xc0 bytes? "Addressed much higher" ... how much higher? I also see that your address is an odd number, have you tried organising it so it's an even numbered address. Some PLC-type devices have shocking bugs with "nonaligned" reads and writes. \$\endgroup\$
    – jonathanjo
    Feb 17, 2023 at 14:22
  • \$\begingroup\$ I used a program called "Modbus Server" to mimic the problematic registers and my application worked correctly. Looking at the response from "Modbus Server" in Wireshark, the nbytes value was 0x0b and there was also no trash. \$\endgroup\$
    – dwp321
    Feb 17, 2023 at 14:31
  • 1
    \$\begingroup\$ My opinion is that the driver has a bug because it shouldn't do anything at all with data after response.byte_count but within the mbp.length. I accept that someone might implement "multiple response in single mbp", in which case you'd expect some kind of error report (because the trash isn't properly formulated modbus reponse); but the standard explicitly says you should only do one message per mbp. The sending device clearly has a bug because it's sending garbage length with garbarge values. \$\endgroup\$
    – jonathanjo
    Feb 18, 2023 at 11:09
  • 1
    \$\begingroup\$ My comment about robustness principle is that in my opinion driver should cope with this buggy reponse, because it's absolutely clear what it should do. Most embedded and process control firmware engineers have no experience of security and are not committed to interoperability. "Well it works with our devices" is usually sufficient in their organisations. This is not satisfactory, in my opinion. \$\endgroup\$
    – jonathanjo
    Feb 18, 2023 at 11:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.