Compute PDU length from MBAP Length field directly.

[TaikiAkita]

For Modbus TCP, the PDU length can be computed directly from the Length field of the header (MBAP).

[cla-bot]

We require contributors to sign our Contributor License Agreement. In order for us to review and merge your code, please fill https://forms.gle/5635zjphDo5JEJQSA to get added. Your document will be manually checked by the maintainer. Be patient...

[TaikiAkita]

CLA signed.

[karlp]

How does this help with anything though?

[TaikiAkita]

How does this help with anything though?

Recently, I tried to use modbus_send_raw_request() and modbus_receive_confirmation() to implement vendor-specific function code.
But the length returned by modbus_receive_confirmation() seems to be incorrect. This patch is intended to fix this problem (currently for Modbus TCP only).
For Modbus RTU, there seems to be no reliable way to fix this issue, since 3.5 chartime is really strict for non-realtime operating systems and there is no Length field (or something like that) in RTU frame.

[cla-bot]

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Ji WenCong.
This is most likely caused by a git client misconfiguration; please make sure to:

1. check if your git client is configured with an email to sign commits git config --list | grep email
2. If not, set it up using git config --global user.email email@example.com
3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

[cla-bot]

We require contributors to sign our Contributor License Agreement. In order for us to review and merge your code, please fill https://forms.gle/5635zjphDo5JEJQSA to get added. Your document will be manually checked by the maintainer. Be patient...

[karlp]

The only right way of handling custom requests is via one of the other PRs, #140 or similar. Your method only helps for tcp, and only for some cases, it doesn't sound like code that should be "standard" in the library?

[TaikiAkita]

The only right way of handling custom requests is via one of the other PRs, #140 or similar. Your method only helps for tcp, and only for some cases, it doesn't sound like code that should be "standard" in the library?

The only right way is following the specification, not a bunch of hacks.
After investigation, the quality of this library can not meet our requirement, so we closed the PR.