Pretty sure I found a bug in the modbus tcp module

Ignition
,
1

So there appears to be a hole in the register map that I’m getting from the mp8k little fuse over modbus tcp. We have a plc local getting data correctly, so the device is not the issue. At address 400532 and 400533 is the hole. I’m getting data in a few ways, int16, uint16, uint16 as 2 decimal fixed point, int32, uint32 as 2 decimal fixed point. If I skip over those 2 addresses and add the extra registers to compensate for the hole after 400533 I get good data. The data before those registers are fine as well. Let me know if you guys need anything from me to fix this.

Thanks,

Jake

2

There’s not a bug, turn off the “Span Gaps” setting if your device can’t handle a read request that spans over one of these holes.

If that’s not the issue then I’m not sure I understand.

3

So the plc will get a uint32 at 400532 and the data is correct. When I use ignition to get that data it seems to be random. If I get that uint32 at 400534 it gets the data that the local plc gets at 400532. I also need to add those 2 registers to everything after that. So 400532 is at 400534, 400534 is at 400536 and so on.

4

Adding 2 registers is strange, usually if anything it’s 1 register to make up for the fact that some documentation starts addresses from 0 and some from 1, even though on the wire the protocol is 0-based.

Get some Wireshark captures and we can compare.

5

Yeah, I was wondering if the HRUS and HRUI was part of it. I can’t get wireshark for the plc, I can for the ignition server. I’m assuming we are looking for the request being made to see if that’s bad.

6

Sure, but without something you think is correct to compare to, it’s not that helpful.

It sounds like maybe an off by one issue and/or you need to enable “Reverse Word Order”.

I’m just guessing without data, though.

7

11:07:49.734956 IP (tos 0x0, ttl 64, id 20486, offset 0, flags [DF], proto TCP (6), length 52)
10.128.0.8.42386 > : Flags [P.], cksum 0xdca2 (incorrect → 0xa19a), seq 653541283:653541295, ack 1480108, win 28400, length 12
0x0000: 4201 0a80 0001 4201 0a80 0008 0800 4500 B…B…E.
0x0010: 0034 5006 4000 4006 0e42 0a80 0008 3f2e .4P.@.@…B…?.
0x0020: 92c6 a592 01f9 26f4 3fa3 0016 95ac 5018 …&.?..P.
0x0030: 6ef0 dca2 0000 1b97 0000 0006 0103 020f n…
0x0040: 0025 .%
11:07:49.899748 IP (tos 0x0, ttl 232, id 63955, offset 0, flags [none], proto TCP (6), length 123)
> 10.128.0.8.42386: Flags [P.], cksum 0x8527 (correct), seq 1:84, ack 12, win 1696, length 83
0x0000: 4201 0a80 0008 4201 0a80 0001 0800 4500 B…B…E.
0x0010: 007b f9d3 0000 e806 fc2c 3f2e 92c6 0a80 .{…,?..
0x0020: 0008 01f9 a592 0016 95ac 26f4 3faf 5018 …&.?.P.
0x0030: 06a0 8527 0000 1b97 0000 004d 0103 4a17 …’…M…J.
0x0040: 6600 0000 5800 8dbe 9800 00bf b800 00c1 f…X…
0x0050: b100 00d9 7000 00de 4600 00dd f300 003d …p…F…=
0x0060: 5900 0058 1e00 0200 0000 004a aa3c 01b7 Y…X…J.<…
0x0070: d900 0000 003e 4a00 0100 0095 7700 0258 …>J…w…X
0x0080: a800 0000 0051 711d 65 …Qq.e
11:07:49.899776 IP (tos 0x0, ttl 64, id 20487, offset 0, flags [DF], proto TCP (6), length 40)
10.128.0.8.42386 > : Flags [.], cksum 0xdc96 (incorrect → 0xc023), seq 12, ack 84, win 28400, length 0
0x0000: 4201 0a80 0001 4201 0a80 0008 0800 4500 B…B…E.
0x0010: 0028 5007 4000 4006 0e4d 0a80 0008 3f2e .(P.@.@…M…?.
0x0020: 92c6 a592 01f9 26f4 3faf 0016 95ff 5010 …&.?..P.
0x0030: 6ef0 dc96 0000 n…
11:08:04.735031 IP (tos 0x0, ttl 64, id 20488, offset 0, flags [DF], proto TCP (6), length 52)
10.128.0.8.42386 > : Flags [P.], cksum 0xdca2 (incorrect → 0xa13a), seq 12:24, ack 84, win 28400, length 12
0x0000: 4201 0a80 0001 4201 0a80 0008 0800 4500 B…B…E.
0x0010: 0034 5008 4000 4006 0e40 0a80 0008 3f2e .4P.@.@…@…?.
0x0020: 92c6 a592 01f9 26f4 3faf 0016 95ff 5018 …&.?..P.
0x0030: 6ef0 dca2 0000 1b98 0000 0006 0103 020f n…
0x0040: 0025 .%
11:08:04.879787 IP (tos 0x0, ttl 232, id 63964, offset 0, flags [none], proto TCP (6), length 123)
> 10.128.0.8.42386: Flags [P.], cksum 0xebc7 (correct), seq 84:167, ack 24, win 1684, length 83
0x0000: 4201 0a80 0008 4201 0a80 0001 0800 4500 B…B…E.
0x0010: 007b f9dc 0000 e806 fc23 3f2e 92c6 0a80 .{…#?..
0x0020: 0008 01f9 a592 0016 95ff 26f4 3fbb 5018 …&.?.P.
0x0030: 0694 ebc7 0000 1b98 0000 004d 0103 4a17 …M…J.
0x0040: 7c00 0000 5500 dabe a200 00bf ad00 00c1 |…U…
0x0050: 9b00 00da 1d00 00da 2f00 00e1 5d00 0040 …/…]…@
0x0060: 2100 0057 4400 0200 0000 004b 233b d8b7 !..WD…K#;…
0x0070: 4f00 0000 003e 4a00 0100 0097 6500 025d O…>J…e…]
0x0080: f600 0000 0053 d11d 65 …S…e
11:08:04.879828 IP (tos 0x0, ttl 64, id 20489, offset 0, flags [DF], proto TCP (6), length 40)
10.128.0.8.42386 > : Flags [.], cksum 0xdc96 (incorrect → 0xbfc4), seq 24, ack 167, win 28400, length 0
0x0000: 4201 0a80 0001 4201 0a80 0008 0800 4500 B…B…E.
0x0010: 0028 5009 4000 4006 0e4b 0a80 0008 3f2e .(P.@.@…K…?.
0x0020: 92c6 a592 01f9 26f4 3fbb 0016 9652 5010 …&.?..RP.
0x0030: 6ef0 dc96 0000 n…
11:08:19.735141 IP (tos 0x0, ttl 64, id 20490, offset 0, flags [DF], proto TCP (6), length 52)
10.128.0.8.42386 > : Flags [P.], cksum 0xdca2 (incorrect → 0xa0da), seq 24:36, ack 167, win 28400, length 12
0x0000: 4201 0a80 0001 4201 0a80 0008 0800 4500 B…B…E.
0x0010: 0034 500a 4000 4006 0e3e 0a80 0008 3f2e .4P.@.@…>…?.
0x0020: 92c6 a592 01f9 26f4 3fbb 0016 9652 5018 …&.?..RP.
0x0030: 6ef0 dca2 0000 1b99 0000 0006 0103 020f n…
0x0040: 0025 .%
11:08:19.880015 IP (tos 0x0, ttl 232, id 63972, offset 0, flags [none], proto TCP (6), length 123)
> 10.128.0.8.42386: Flags [P.], cksum 0x197c (correct), seq 167:250, ack 36, win 1672, length 83
0x0000: 4201 0a80 0008 4201 0a80 0001 0800 4500 B…B…E.
0x0010: 007b f9e4 0000 e806 fc1b 3f2e 92c6 0a80 .{…?..
0x0020: 0008 01f9 a592 0016 9652 26f4 3fc7 5018 …R&.?.P.
0x0030: 0688 197c 0000 1b99 0000 004d 0103 4a17 …|…M…J.
0x0040: 7c00 0000 5c00 e2be 8a00 00bf 1c00 00c1 |…
0x0050: 7d00 00de b000 00d7 4900 00de d800 003f }…I…?
0x0060: 0f00 0053 d100 0200 0000 004a f93c 03b6 …S…J.<…
0x0070: 9600 0000 003e 4d00 0100 0092 e000 025e …>M…^
0x0080: 9b00 0000 0056 4d1d 65 …VM.e
11:08:19.880068 IP (tos 0x0, ttl 64, id 20491, offset 0, flags [DF], proto TCP (6), length 40)
10.128.0.8.42386 > : Flags [.], cksum 0xdc96 (incorrect → 0xbf65), seq 36, ack 250, win 28400, length 0
0x0000: 4201 0a80 0001 4201 0a80 0008 0800 4500 B…B…E.
0x0010: 0028 500b 4000 4006 0e49 0a80 0008 3f2e .(P.@.@…I…?.
0x0020: 92c6 a592 01f9 26f4 3fc7 0016 96a5 5010 …&.?..P.
0x0030: 6ef0 dc96 0000 n…
11:08:34.734447 IP (tos 0x0, ttl 64, id 20492, offset 0, flags [DF], proto TCP (6), length 52)
10.128.0.8.42386 > : Flags [P.], cksum 0xdca2 (incorrect → 0xa07a), seq 36:48, ack 250, win 28400, length 12
0x0000: 4201 0a80 0001 4201 0a80 0008 0800 4500 B…B…E.
0x0010: 0034 500c 4000 4006 0e3c 0a80 0008 3f2e .4P.@.@…<…?.
0x0020: 92c6 a592 01f9 26f4 3fc7 0016 96a5 5018 …&.?..P.
0x0030: 6ef0 dca2 0000 1b9a 0000 0006 0103 020f n…
0x0040: 0025 .%
11:08:34.880207 IP (tos 0x0, ttl 232, id 63981, offset 0, flags [none], proto TCP (6), length 123)
> 10.128.0.8.42386: Flags [P.], cksum 0xdd23 (correct), seq 250:333, ack 48, win 1660, length 83
0x0000: 4201 0a80 0008 4201 0a80 0001 0800 4500 B…B…E.
0x0010: 007b f9ed 0000 e806 fc12 3f2e 92c6 0a80 .{…?..
0x0020: 0008 01f9 a592 0016 96a5 26f4 3fd3 5018 …&.?.P.
0x0030: 067c dd23 0000 1b9a 0000 004d 0103 4a17 .|.#…M…J.
0x0040: 6600 0000 4a00 c8be f500 00c0 1a00 00c1 f…J…
0x0050: b000 00df e100 00da 0600 00e1 9200 003b …;
0x0060: 5900 0053 2100 0200 0000 004a 7a3c 48b7 Y…S!..Jz<H.
0x0070: 8e00 0000 003e 4a00 0100 008e 7a00 0260 …>J…z…`
0x0080: 8400 0000 0058 af1d 65 …X…e
11:08:34.880236 IP (tos 0x0, ttl 64, id 20493, offset 0, flags [DF], proto TCP (6), length 40)
10.128.0.8.42386 > : Flags [.], cksum 0xdc96 (incorrect → 0xbf06), seq 48, ack 333, win 28400, length 0
0x0000: 4201 0a80 0001 4201 0a80 0008 0800 4500 B…B…E.
0x0010: 0028 500d 4000 4006 0e47 0a80 0008 3f2e .(P.@.@…G…?.
0x0020: 92c6 a592 01f9 26f4 3fd3 0016 96f8 5010 …&.?..P.
0x0030: 6ef0 dc96 0000 n…

8

let me know if you see anthing, I’m analyzing now, thx

9

0103 020f 0025 looks correct, grabbing 37 holding registers starting at 527 from device id 1. So it’s seeming like a bug still. What are your thoughts? I can compensate for it but would hate for a fix to all of sudden screw up the workaround.Thx, jake

10

Can you upload the capture files somewhere (here, or wherever)?

11

packet.pcap (7.2 KB)

There you go.Thx

12

image
image1040×346 27.1 KB

13

it’s tcpdump with -XXA, did you want a binary capture, think wireshark will read that

14

Yes, I think you’ll need to capture it in binary format.

https://osqa-ask.wireshark.org/questions/19054/tcpdump-text-output-to-pcap/

15

Let me know if this loads.Thx

16

Yes, it works.

So what tag in Ignition has data you don’t expect in it? What’s the address you are using, and is the driver configured for 1- or 0-based addressing?

17

So those packets are filtered for only the data from the mp8k. There’s like 15 tags in the response, int16, uint16, uint16 as 2 decimal floats, int32, uint32 and uint32 as 2 decimal floats. It’s in 1 based and I compensate in the tag. The problem starts at [{VoltageMonitor}]1.HRUI532, which is the first 32bit value, it’s a fixed point with 2 bytes after the decimal. It seems to create a hole that I must advance the offsets from that tag and above.Thx

18

Scaling aside, if you read 1.HRUI532 then according to this capture the value would be 0xBEAC0000 (3198943232), or if you had word swapping enabled 0x0000BEAC (48812).

19

You do understand that Modbus has nothing but 16-bit registers, and that larger types are built by reading and combining two or more registers?

If you have a block of 32-bit values then, yes, you will start skipping register numbers, because each value is built using 2 registers.

20

Yes, I know the modbus protocol is old and many implementations have compensated for it’s limitations:). It was just odd to me that the data seems correct if I slid the stuff after those 2 registers. Another thing too is java doesn’t support unsigned natively, I’ve had to write a library to compensate for that, long ago though, so maybe they added the unsigned support by now:). I’ll try the byte swapping and see what it looks like, but I noticed the packets seem to have valid modbus packet headers in the right order.