Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TCP: behaviour for "unit identifier == 0" makes little sense. #376

Closed
magthe opened this issue Apr 6, 2017 · 3 comments
Closed

TCP: behaviour for "unit identifier == 0" makes little sense. #376

magthe opened this issue Apr 6, 2017 · 3 comments

Comments

@magthe
Copy link

magthe commented Apr 6, 2017

libmodbus version

3.1.4

OS and/or distribution

Linux (ArchLinux)

Environment

64 bit

Description

I sent a message using ModbusTCP with a "unit identifier" of 0.

Expected behaviour

A response to the message.

Actual behaviour

No response is sent.

Suspected place of bug

I think the bug is here. I'm guessing, without having studied the code in detail, that the TCP request frame is scaled down to match an RTU frame. This means that the "unit identifier" has the same location as "slave address". The line I pointed to will drop responses for "slave address == 0".

This behaviour is, AFAIU, not according to standard. I can also not find any documentation of it.

mhei added a commit to mhei/libmodbus that referenced this issue Apr 7, 2017
According to the Modbus standard, the unit identifier is choosen by the
TCP client and can be any value:

"This field is used for intra-system routing purpose.  It is typically
used to communicate to a MODBUS+ or a MODBUS serial line slave through a
gateway between an Ethernet TCP-IP network and a MODBUS serial line.
This field is set by the MODBUS Client in the request and must be returned
with the same value in the response by the server."

So the current check in modbus_reply must be extended to check whether
we are in a RTU or TCP context.

Also the unit-test has to be adjusted.

Signed-off-by: Michael Heimpold <[email protected]>
@mhei
Copy link
Contributor

mhei commented Apr 7, 2017

I would agree that this is a bug because as of my understanding the unit identifier can take any value. This is because a broadcast does not make sense in a TCP context - only when the Modbus server is a "Modbus TCP to RTU proxy"...
So could you try whether the patch in my branch fixes your issue?

@magthe
Copy link
Author

magthe commented Jul 3, 2017

Yupp, looks good!

@stephane
Copy link
Owner

stephane commented Jul 3, 2017

Thank you @mhei and @magthe

georgidimov pushed a commit to georgidimov/libmodbus that referenced this issue Jul 24, 2017
According to the Modbus standard, the unit identifier is choosen by the
TCP client and can be any value:

"This field is used for intra-system routing purpose.  It is typically
used to communicate to a MODBUS+ or a MODBUS serial line slave through a
gateway between an Ethernet TCP-IP network and a MODBUS serial line.
This field is set by the MODBUS Client in the request and must be returned
with the same value in the response by the server."

So the current check in modbus_reply must be extended to check whether
we are in a RTU or TCP context.

Also the unit-test has to be adjusted.

Signed-off-by: Michael Heimpold <[email protected]>
epsilonrt pushed a commit to epsilonrt/libmodbus that referenced this issue Jun 19, 2023
According to the Modbus standard, the unit identifier is choosen by the
TCP client and can be any value:

"This field is used for intra-system routing purpose.  It is typically
used to communicate to a MODBUS+ or a MODBUS serial line slave through a
gateway between an Ethernet TCP-IP network and a MODBUS serial line.
This field is set by the MODBUS Client in the request and must be returned
with the same value in the response by the server."

So the current check in modbus_reply must be extended to check whether
we are in a RTU or TCP context.

Also the unit-test has to be adjusted.

Signed-off-by: Michael Heimpold <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants