Partner connection

[hs2bws-hash]

First of all, thank you very much for your work on this great project.

I tried to convert an existing application that works with the classic version of Python-Snap7 to the Python-only version.

The application (running on a Raspberry Pi 4) is supposed to connect as an active partner to an S7-1500. While it connects immediately with the classic version of python-snap7, I haven't been able to connect with the Python-only version. get_status() reports status 2 - connected, while the PLC remains in status 3 (awaitung connection). connection.check_connection() changes from True to False after a few seconds, get_status() rests in status 2.

The connection:
Local port and remote port: 102
Local tsap: 0x1300
Remote tsap: 0x1301
Local IP: 192.168.0.96
PLC IP: 192.168.0.100

PLC:
CPU 1511-1 PN
6ES7 511-1AK01-0AB0
Firmware V2.9

Debug output:
[DEBUG]: TCP connected to 192.168.0.100:102
[DEBUG]: Sent COTP Connection Request
[DEBUG]: Negotiated PDU size: 1024
[DEBUG]: Unsupported COTP parameter: code=0xc1, length=2
[DEBUG]: Unsupported COTP parameter: code=0xc2, length=2
[DEBUG]: Received COTP Connection Confirm
[INFO]: Connected to 192.168.0.100:102, PDU size: 1024
[INFO]: Connected to remote partner at 192.168.0.100:102
[INFO]: Partner started (active mode)

Any idea what the problem could be? I'd be happy to run further tests...

Something else I've noticed: on the PLC in b_send and b_recv, the data packet is addressed with an "R-ID". However, I'm missing this in the partner module. Is this not yet implemented, or am I misunderstanding something?

[gijzelaerr]

Thanks for the detailed report and for offering to test!

You identified the problems correctly. The pure Python partner implementation had two issues:

1. Missing S7 Communication Setup — After the COTP connection completes, the partner needs to perform an S7 Communication Setup exchange (same as the client does) to negotiate the PDU size. Without this, the PLC stays in "awaiting connection" because the S7-level session was never established. This also explains why check_connection() goes from True to False after a few seconds — the PLC closes the connection when it doesn't receive the expected S7 setup.

2. Missing R-ID in bsend/brecv — You're right, the R-ID was not implemented. The partner data PDUs now use the proper S7 USERDATA format (type 0x07) with function group 6 (push) and include the R-ID for bsend/brecv matching. You can set it via partner.r_id = <your_value> before calling b_send()/b_recv().

Both are fixed in #669. Could you test it with your S7-1500 setup? You can install from the branch with:

pip install git+https://github.com/gijzelaerr/python-snap7.git@fix-partner-s7-setup

Note that for port 102 you'll need to set partner.port = 102 since the default is 1102.

[hs2bws-hash]

Great, with the new version I can establish a connection to the PLC, thank you!

Next, I wanted to transmit data using b_send. I set r_id to 0x1 on both sides, with set_send_data put a 20-byte array. b_send has returned 0.

On the PLC side, brcv then always remains in status 25 (Communication has been initiated. The order is being processed). It seems that the PLC is still waiting for something. If the data is sent again, the status is still 25.

[DEBUG]: TCP connected to 192.168.0.100:102
[DEBUG]: Sent COTP Connection Request
[DEBUG]: Negotiated PDU size: 1024
[DEBUG]: Unsupported COTP parameter: code=0xc1, length=2
[DEBUG]: Unsupported COTP parameter: code=0xc2, length=2
[DEBUG]: Received COTP Connection Confirm
[INFO]: Connected to 192.168.0.100:102, PDU size: 1024
[DEBUG]: Sent 25 bytes: 03 00 00 19 02 f0 80 32 01 00 00 00 01 00 08 00 00 f0 00 00 01 00 01 01 e0
[DEBUG]: Received TPKT: version=3 length=27 payload (23 bytes): 02 f0 80 32 03 00 00 00 01 00 08 00 00 00 00 f0 00 00 01 00 01 01 e0
[INFO]: S7 Communication Setup complete, PDU length: 480
[INFO]: Connected to remote partner at 192.168.0.100:102
[INFO]: Partner started (active mode)

[DEBUG]: Sent 57 bytes: 03 00 00 39 02 f0 80 32 07 00 00 00 02 00 10 00 18 00 01 12 08 11 46 01 02 00 00 00 00 00 00 00 01 ff 09 00 14 00 00 00 0a 00 00 00 19 00 00 73 c0 00 00 75 f8 ff ff a8 b2
[DEBUG]: Received TPKT: version=3 length=41 payload (37 bytes): 02 f0 80 32 07 00 00 00 02 00 0c 00 0c 00 01 12 08 12 86 01 02 00 00 84 04 ff 09 00 08 12 06 13 00 00 00 00 00
[DEBUG]: Sent 20 bytes synchronously

[gijzelaerr]

Thanks for testing and the detailed debug output — it was very helpful for pinpointing the issue!

The problem was in the BSend PDU format. Two things were wrong:

1. Wrong subfunction: The code was using subfunction 0x01 (push notification) instead of 0x06 (BSend). This is why the PLC responded with error 0x8404 — it recognized the USERDATA push PDU but didn't understand it as a BSend request.

2. Parameter header too long: The parameter sub-length was 0x08 (including data_unit_ref, last_data_unit, and error_code fields) when BSend requests should use 0x04 (just method, type/group, subfunction, sequence).

Both are fixed in the latest push to #669. You can update with:

pip install git+https://github.com/gijzelaerr/python-snap7.git@fix-partner-s7-setup

Also added error code checking in the ACK parser — previously b_send() returned 0 even when the PLC sent back an error. Now it will raise an S7Error with the error code if the PLC rejects the push.

[hs2bws-hash]

Unfortunately, my PLC is still not satisfied. Now it responds with error 0x8104

[DEBUG]: Sent 53 bytes: 03 00 00 35 02 f0 80 32 07 00 00 00 02 00 0c 00 18 00 01 12 04 11 46 06 02 00 00 00 01 ff 09 00 14 00 00 00 0b 00 00 00 17 00 00 73 ee 00 00 75 f8 ff ff a8 b2
[DEBUG]: Received TPKT: version=3 length=33 payload (29 bytes): 02 f0 80 32 07 00 00 00 02 00 0c 00 04 00 01 12 08 12 86 06 02 00 00 81 04 0a 00 00 00
[ERROR]: Synchronous send failed: Partner ACK error: 0x8104

[hs2bws-hash]

Here's a screenshot from Wireshark of a package from the working, classic Python-snap7 version.

[gijzelaerr]

Thanks for the Wireshark capture — it was very helpful. I've pushed a second fix to the fix-partner-s7-setup branch (PR #669) that corrects the BSend PDU format to match the PBC (Program Block Communication) protocol:

Changes:

• Method byte: 0x12 (push) instead of 0x11 (request)
• Type/Group byte: 0x06 (push|PBC) instead of 0x46 (request|PBC)
• Added dur/ldu/error_code fields in the USERDATA parameter header
• Added the variable specification block (12 06 82 41 ...) with payload length after the R-ID
• Added PBC prefix (12 00) before the payload in the data section

The parameter section now matches the 24-byte format seen in the working Wireshark capture. Would you be able to test this against the real S7-1500 again?

[hs2bws-hash]

Since I was still getting an error message from the PLC, I tried to adjust the _build_partner_data_pdu function to produce the same result as the Wireshark capture. Here's the result:

    def _build_partner_data_pdu(self, data: bytes, r_id: Optional[int] = None) -> bytes:
        """Build an S7 USERDATA PDU for partner data push (bsend).

        The PDU uses the standard S7 USERDATA header (10 bytes) followed by
        a parameter section that identifies this as a PBC (Program Block
        Communication) push with the R-ID and a variable specification
        block, and a data section with the payload.

        Args:
            data: Payload to send.
            r_id: Request ID for bsend/brecv matching.  Falls back to ``self.r_id``.

        Returns:
            Complete S7 PDU bytes (without COTP/TPKT framing).
        """
        if r_id is None:
            r_id = self.r_id

        sequence = self._protocol._next_sequence()

        # Parameter section: USERDATA header with PBC variable specification
        param = struct.pack(
            ">BBBBBBBBBBH",
            0x00,  # reserved
            0x01,  # parameter count
            0x12,  # type header
            0x08,  # length of following parameter data
            0x12,  # Syntax ID Parameter extendet
            #0x06,  # type 0 (push) | group 6 (PBC)
            0x46,  # 01... .... type 1 (request) | ..00 0110 group 6 (PBC BSEND)  
            #_PUSH_SUBFUNCTION_BSEND,
            0x01,  # subfunction
            #sequence & 0xFF,
            0x00,  # sequence number
            0x00,  # data unit reference number
            0x00,  # last data unit
            0x0000,  # error code
        )
        
        # Dataheader  Return code: 0xff (success), Transportsize: 0x09 (octet string), Length: data+10
        data_section = struct.pack(">BBH", 0xff, 0x09, len(data)+10)
        # Variable specification block: type=0x12, len=0x06, transport=0x13, PBC unknown
        data_section += struct.pack(">BBBB", 0x12, 0x06, 0x13, 0x00)
        # R-ID (4 bytes)
        data_section += struct.pack(">I", r_id)
        # payload_length
        data_section += struct.pack(">H", len(data))

        data_section += data
        
        # S7 USERDATA header (10 bytes)
        header = struct.pack(
            ">BBHHHH",
            0x32,
            S7PDUType.USERDATA,
            0x0000,
            sequence,
            len(param),
            len(data_section),
        )

        return header + param + data_section

Main changes:

• Type/Group byte: 0x46 (request|PBC was correct
• Sequence number in the parameters must be 0
• _PUSH_SUBFUNCTION_BSEND = 1
• Position of the r_id after the variable specification block
• payload_length after the r_id

This allowed me to successfully initiate the communication. Now the 20 bytes are transmitted to the PLC 10 times per second.

I will try to receive data from the PLC when I have the opportunity. If I saw correctly, async receive is not yet implemented.

[gijzelaerr]

Thanks for testing against the real PLC and sharing the working code! I've updated the PR with your corrections:

• Type/Group byte: 0x46 (request|PBC) — was correct originally, reverted
• Subfunction: 0x01 instead of 0x06
• Sequence number in parameter: always 0 for PBC
• R-ID moved from parameter section to data section variable specification block
• Data section format: 12 06 13 00 (var spec) + R-ID (4 bytes) + payload length (2 bytes) + payload
• Parser updated to strip the 10-byte PBC var spec prefix from incoming data

Great to hear BSend is now working. For BRecv — you're right that the async receive path isn't fully wired up yet. The b_recv() synchronous method should work for receiving data from the PLC though. Let us know how it goes!

[gijzelaerr]

Also added the async receive path in the latest push to this branch:

• as_b_recv() — start non-blocking receive
• wait_as_b_recv_completion(timeout) — block until data arrives
• check_as_b_recv_completion() — poll for completion
• set_recv_callback(callback) / set_send_callback(callback) — now actually register callbacks (were no-op stubs before)

A background listener thread monitors the socket for incoming data, parses the PDU, sends the ACK, and queues the result. Thread-safe I/O coordination between send and receive via a lock.

[hs2bws-hash]

Thank you very much for the improvements.

I haven't tested the new code yet, but I've managed to get the BRCV working by adjusting the following functions:

    def _parse_partner_data_pdu(self, pdu: bytes) -> Tuple[bytes, int, int]:
        """Parse an incoming partner data push PDU and extract the payload.

        Accepts both the new USERDATA format (with R-ID) and the legacy
        minimal format for backward-compatibility with existing tests that
        use raw socket pairs.

        Returns:
            The application payload.
        """
        if len(pdu) < 6:
            raise S7Error("Invalid partner PDU: too short")

        protocol_id, pdu_type = struct.unpack(">BB", pdu[:2])

        if protocol_id != 0x32:
            raise S7Error(f"Invalid protocol ID: {protocol_id:#04x}")

        if pdu_type == S7PDUType.USERDATA:
            # Full USERDATA format
            if len(pdu) < 10:
                raise S7Error("USERDATA partner PDU too short")
            _, _, _, pduref, param_len, data_len = struct.unpack(">BBHHHH", pdu[:10])
            data_offset = 10 + param_len
            if data_offset + 4 > len(pdu):
                raise S7Error("Partner data section too short")
            # Skip 4-byte data section header (return_code, transport_size, length)
            payload = pdu[data_offset + 4 : data_offset + 4 + data_len - 4] if data_len > 4 else b""
            # Variable specifikation
            if len(payload) >= 2 and payload[0] == 0x12:
                payload = payload[1:]
                if len(payload) >= 2:
                    var_spez_len = payload[0]
                    if var_spez_len == 6:
                        syntax_id, _, r_id  = struct.unpack(">BBI", payload[1:7])
                        if syntax_id == 0x13:
                            payload = payload[9:]
                            return payload, r_id, pduref
            return payload, 0
        
        else:
            raise S7Error(f"Unexpected PDU type in partner data: {pdu_type:#04x}")

Changes:

• Additional return values ​​r_id and pduref (Protocol Data Unit Reference)
• Check the Variable specifikation
• Extract the ​​r_id and pduref

    def _build_partner_ack(self, pduref: [int]) -> bytes:
        """Build an S7 USERDATA acknowledgment PDU for a received bsend.

        Args:
            #r_id: Request ID echoed from the data PDU.
            pduref: Protocol Data Unit reference

        Returns:
            Complete S7 PDU bytes.
        """
#         if r_id is None:
#             r_id = self.r_id

        sequence = self._protocol._next_sequence()

        param = struct.pack(
            ">BBBBBBBB",
            0x00,
            0x01,
            0x12,
            0x08,  # length: 4 base + 2 (dur/ldu) + 2 (error code)
            0x12,  # method: response
            0x86,  # type 8 (response) | group 6 (push)
            _PUSH_SUBFUNCTION_BSEND,
            sequence & 0xFF, 
        )
        #param += struct.pack(">BBHI", 0x00, 0x00, 0x0000, r_id)  # dur, ldu, error_code, R-ID
        param += struct.pack(">BBH", 0x00, 0x00, 0x0000)  # dur, ldu, error_code
        #data return code, length
        data = struct.pack(">BBH", 0x0a, 0x00, 0x0000)


        header = struct.pack(
            ">BBHHHH",
            0x32,
            S7PDUType.USERDATA,
            0x0000,
            pduref,
            len(param),
            len(data),
        )

        return header + param + data

Changes:

• New parameter: pduref (r-id is not needed)
• Separate Data part (4 byte)
• pduref + data length in the header

The PLC expects the same Protocol Data Unit Reference number in the acknowledgment as in the data transmission in order to complete the transmission.