Ask Your Question

Revision history [back]

Modbus/TCP decoding "func 3" seems wrong

Hello. I am a novice WS user and I have an issue with the Modbus/TCP decoder that I can't figure out.

I send a function 3 (read holding registers), which gets transaction ID $0002 and asks for 24 bytes to be returned. send payload is: 00 02 00 00 00 06 01 03 03 84 00 0C

The response (per the decoder) is shown as function 24 (!), with transaction ID 512 ($0200).
It seems to ignore the first byte [00] and interprets as: [00] 02 00 00 00 1B 01 03 18 (followed by 12 data bytes)

If I mouseover data bytes in the sent transaction, it shows the first 00 as mbtcp.trans_id which is correct.

If I mouseover the data bytes in the response, it shows [00] as tcp.payload, but mbtcp.trans_id is not displayed until the 02 byte, which seems wrong; it has skipped the 00 in the transaction ID!

If I disable the decoder and look at the raw bytes, they appear correct.

If I hack my code to add a dummy byte of A5 as the first byte in the payload, the decoder then displays the fund 3 query and reply correctly.

I have cap files of these, if there is a way I can attach them...?

Thank you

Modbus/TCP decoding "func 3" seems wrong

Hello. I am a novice WS user and I have an issue with the Modbus/TCP decoder that I can't figure out.

I send a function 3 (read holding registers), which gets transaction ID $0002 and asks for 24 bytes to be returned. send payload is: 00 02 00 00 00 06 01 03 03 84 00 0C

The response (per the decoder) is shown as function 24 (!), with transaction ID 512 ($0200).
It seems to ignore the first byte [00] and interprets as: [00] 02 00 00 00 1B 01 03 18 (followed by 12 data bytes)

If I mouseover data bytes in the sent sent transaction, it shows the first 00 as mbtcp.trans_id which is correct.

If I mouseover the data bytes in the response, response, it shows [00] as tcp.payload, but mbtcp.trans_id is not displayed until the 02 byte, which seems wrong; it has skipped the 00 in the transaction ID!

If I disable the decoder and look at the raw bytes, they appear correct.

If I hack my code to add a dummy byte of A5 as the first byte in the payload, the decoder then displays the fund func 3 query and reply correctly.

I have cap files of these, if there is a way I can attach them...?

Thank you

Modbus/TCP decoding "func 3" seems wrong

Hello. I am a novice WS user and I have an issue with the Modbus/TCP decoder that I can't figure out.

I send a function 3 (read holding registers), which gets transaction ID $0002 and asks for 24 bytes to be returned. send payload is: 00 02 00 00 00 06 01 03 03 84 00 0C

The response (per the decoder) is shown as function 24 (!), with transaction ID 512 ($0200).
It seems to ignore the first byte [00] and interprets as: [00] 02 00 00 00 1B 01 03 18 (followed by 12 data bytes)

If I mouseover data bytes in the sent transaction, it shows the first 00 as mbtcp.trans_id which is correct.

If I mouseover the data bytes in the response, it shows [00] as tcp.payload, but mbtcp.trans_id is not displayed until the 02 byte, which seems wrong; it has skipped the 00 in the transaction ID!

If I disable the decoder and look at the raw bytes, they appear correct.

If I hack my code to add a dummy byte of A5 as the first byte in the payload, the decoder then displays the func 3 query and reply correctly.

I have cap files showing spurious function code 24: https://www.dropbox.com/s/armxpv99pygp5rn/spurious_24_instead_of_3.pcapng?dl=0

with A5 byte added at start of these, if there is a way I can attach them...?

Thank youpayload, no spurious function 24: https://www.dropbox.com/s/gb7484nwr8nvd1u/added_A5_byte.pcapng?dl=0

Modbus/TCP decoding "func 3" seems wrong

Hello. I am a novice WS user and I have an issue with the Modbus/TCP decoder that I can't figure out.

I send a function 3 (read holding registers), which gets transaction ID $0002 and asks for 24 bytes to be returned. send payload is: 00 02 00 00 00 06 01 03 03 84 00 0C

The response (per the decoder) is shown as function 24 (!), with transaction ID 512 ($0200).
It seems to ignore the first byte [00] and interprets as: [00] 02 00 00 00 1B 01 03 18 (followed by 12 data bytes)

If I mouseover data bytes in the sent transaction, it shows the first 00 as mbtcp.trans_id which is correct.

If I mouseover the data bytes in the response, it shows [00] as tcp.payload, but mbtcp.trans_id is not displayed until the 02 byte, which seems wrong; it has skipped the 00 in the transaction ID!

If I disable the decoder and look at the raw bytes, they appear correct.

If I hack my code to add a dummy byte of A5 as the first byte in the payload, the decoder then displays the func 3 query and reply correctly.

showing spurious function code 24: https://www.dropbox.com/s/armxpv99pygp5rn/spurious_24_instead_of_3.pcapng?dl=0

with A5 byte added at start of payload, no spurious function 24: https://www.dropbox.com/s/gb7484nwr8nvd1u/added_A5_byte.pcapng?dl=0

Note: I am using the latest version of WS available from the Debian repo, but I see that is 2.6.8, which is not very new.