New MAX_PDU_SIZE limits systems that work beyond that limit via custom functions

[NSchrading]

v0.16.0 introduced a hardcoded limit on the MAX_PDU_SIZE: v0.15.0...v0.16.0#diff-8dfd85153dbfd0c2fe0b29f7eb8d53fbda43f2f2cc71cfca8fa6402dba78db00R26

But I have a system (labjack, modbus tcp) that has been working with larger packet sizes on v0.15. Their limit is a max ethernet packet size of 1040 bytes. By maintaining this limit, I can reduce the number of sequential reads on the device when doing fancier things like reading N bytes (where N is potentially large) from a buffer register: https://support.labjack.com/docs/3-1-modbus-map-t-series-datasheet#id-3.1ModbusMap[T-SeriesDatasheet]-BufferRegisters

They implement a custom modbus function that supports these larger packet sizes: https://support.labjack.com/docs/protocol-details-direct-modbus-tcp#ProtocolDetails[DirectModbusTCP]-ModbusFeedback(MBFB,function#76)

Can the restriction be relaxed, perhaps if using custom modbus functions or when using modbus tcp?

[uklotzde]

Customization seems to be difficult, because there is no context during decoding in the TryFrom trait impls.

Then we should probably disable these checks for custom function requests and responses.

[uklotzde]

Please check if #307 works for your use case.

[NSchrading]

Thanks for the quick response! I tried that branch and it passed all of my integration tests, where previously a few were failing on the MAX_PDU_SIZE check. So I think for my system, that change works.

[uklotzde]

Disabling the check for the custom function codes is probably the expected behavior. The custom handlers are responsible for decoding and validating the received bytes.