Async server might get the wrong UID from the incoming packet.

[kierun]

Versions

• Python: 2.7.5
• OS: CentOS Linux release 7.4.1708 (Core)
• Pymodbus: 1.4.0
• Modbus Hardware (if used): N.A.

Pymodbus Specific

• Server: tcp - async -- Python using pymodbus.
• Client: tcp - async -- C++, external code.

Description

I have a python async server and I am using that to test a C++ client.

Note that the client works fine with the hardware. I am writing a simulator so that we can work on the client code without having to have hardware at our disposition.

The client disconnects as soon as the transmission identification spill over to the first byte of the packet. The Python async dataReceived assumes the following:

            def dataReceived(self, data):
            […]
            unit_address = byte2int(data[0])  # ← Should be 6 instead of 0?
            if unit_address in self.factory.store:
                self.framer.processIncomingPacket(data, self._execute)

This does not look correct. It should be:

unit_address = byte2int(data[6]) - 1

At least according to the docstring in ModbusSocketFramer.

The client code connects fine as long as the first byte is 0x0 but that only lasts so long.

Note that stores are zero indexed but the UID start at one. At least, for our hardware it is a 1 (one). thus why I am subtracting one from the byte2int(data[6]).

If I modify the code like above, our client code stays connected for a long time.

Changing

Code and Logs

I have added some debugging to show the unit_address, the rest of the log file is vanilla.

2018-03-06 09:30:44,758 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x0 0xfd 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:44,758 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 0. In factory store? True
2018-03-06 09:30:44,758 [9874.MainThread] DEBUG    [pymodbus.transaction (transaction:463)] 0x0 0xfd 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:44,758 [9874.MainThread] DEBUG    [pymodbus.factory (factory:130)] Factory Request[3]
2018-03-06 09:30:44,759 [9874.MainThread] DEBUG    [pymodbus.datastore.context (context:62)] validate[3] 10:30
2018-03-06 09:30:44,759 [9874.MainThread] DEBUG    [pymodbus.datastore.context (context:74)] getValues[3] 10:30
2018-03-06 09:30:44,759 [9874.MainThread] DEBUG    [pymodbus.server.async (async:98)] send: 00fd0000003f01033c0000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d4
2018-03-06 09:30:45,258 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x0 0xfe 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:45,258 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 0. In factory store? True
2018-03-06 09:30:45,259 [9874.MainThread] DEBUG    [pymodbus.transaction (transaction:463)] 0x0 0xfe 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:45,259 [9874.MainThread] DEBUG    [pymodbus.factory (factory:130)] Factory Request[3]
2018-03-06 09:30:45,259 [9874.MainThread] DEBUG    [pymodbus.datastore.context (context:62)] validate[3] 10:30
2018-03-06 09:30:45,259 [9874.MainThread] DEBUG    [pymodbus.datastore.context (context:74)] getValues[3] 10:30
2018-03-06 09:30:45,259 [9874.MainThread] DEBUG    [pymodbus.server.async (async:98)] send: 00fe0000003f01033c0000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d4
2018-03-06 09:30:45,759 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x0 0xff 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:45,759 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 0. In factory store? True
2018-03-06 09:30:45,760 [9874.MainThread] DEBUG    [pymodbus.transaction (transaction:463)] 0x0 0xff 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:45,760 [9874.MainThread] DEBUG    [pymodbus.factory (factory:130)] Factory Request[3]
2018-03-06 09:30:45,760 [9874.MainThread] DEBUG    [pymodbus.datastore.context (context:62)] validate[3] 10:30
2018-03-06 09:30:45,761 [9874.MainThread] DEBUG    [pymodbus.datastore.context (context:74)] getValues[3] 10:30
2018-03-06 09:30:45,761 [9874.MainThread] DEBUG    [pymodbus.server.async (async:98)] send: 00ff0000003f01033c0000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d40000000030d4
2018-03-06 09:30:46,259 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x1 0x0 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:46,260 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 1. In factory store? False
2018-03-06 09:30:46,760 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x1 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:46,760 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 1. In factory store? False
2018-03-06 09:30:47,260 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x1 0x2 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:47,260 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 1. In factory store? False
2018-03-06 09:30:47,761 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x1 0x3 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:47,762 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 1. In factory store? False
2018-03-06 09:30:48,261 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x1 0x4 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:48,262 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 1. In factory store? False
2018-03-06 09:30:48,762 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x1 0x5 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:48,762 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 1. In factory store? False
2018-03-06 09:30:49,262 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x1 0x6 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:49,263 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 1. In factory store? False
2018-03-06 09:30:49,763 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x1 0x7 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:49,763 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 1. In factory store? False
2018-03-06 09:30:50,263 [9874.MainThread] DEBUG    [pymodbus.server.async (async:60)] 0x1 0x8 0x0 0x0 0x0 0x6 0x1 0x3 0x0 0xa 0x0 0x1e
2018-03-06 09:30:50,264 [9874.MainThread] DEBUG    [pymodbus.server.async (async:64)] unit address: 1. In factory store? False
2018-03-06 09:30:50,763 [9874.MainThread] DEBUG    [pymodbus.server.async (async:52)] Client Disconnected: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly.
]
2018-03-06 09:33:35,255 [9874.MainThread] WARNING  [CommandLineInterface (command_line:101)] Connection lost because <twisted.python.failure.Failure twisted.internet.error.ConnectionDone: Connection was closed cleanly.>

[kierun]

If this is indeed a bug, I am happy to write a PR. Probably the shortest PR ever, but still. ☺

[dhoomakethu]

@kierun Please check the branch https://github.com/riptideio/pymodbus/compare/%23256-Fix-TCP-Server-Transactions#diff-ee743422eb414b680c3227dab6427f4aL62, there is a fix for this already (only for TCP but breaks for RTU). I will get this to 1.5.0 ASAP.
Thanks

[kierun]

I might have found a bug in the fix…

The sync version does scale the uid to a zero index. However, the async version does not.

[dhoomakethu]

Thanks for the report. The fix is still work under progress and that's the reason it is still lying around for some time. I am short of hands and time. I will try to see if this is addressed asap. If you think you have a solution which works for both sync and async versions, please feel free to raise a PR.

[kierun]

I am wrong. You can set the ModbusServerContext's slaves to use whatever index you want. I should do that, not munge incoming data.

I should be doing this:

    store = ModbusSlaveContext(
        zero_mode=True,
        di=ModbusSparseDataBlock(_get_data(cfg, 'discrete_inputs')),
        co=ModbusSparseDataBlock(_get_data(cfg, 'coils')),
        hr=ModbusSparseDataBlock(_get_data(cfg, 'holding_register')),
        ir=ModbusSparseDataBlock(_get_data(cfg, 'input_registers')))
    context = ModbusServerContext(slaves={1: store}, single=False)

Where get_data reads the data from a ConfigObj initialisation file and should not impact anything here.

---

Are you happy to leave this open till 1.5.0 is released?

[dhoomakethu]

Yup, I don't mind. I Might have a release by the end of this month though.

[kierun]

That would be great. Many thanks indeed for your efforts and quick replies. Much appreciated.

[dhoomakethu]

Fixed with v1.5.0 , refer dev branch or release