build_userdata_followup_request: parameter block differs from the real engineering tool and the native Snap7 client #948

S7Protocol.build_userdata_followup_request builds the follow-up request for multi-packet USER_DATA responses (SZL, list blocks of type) with an 8-byte parameter block and method 0x11. Every independent source I can find sends a 12-byte block with method 0x12 instead.

Reproduction (python-snap7 3.0.0 and 3.2.1, same bytes):

from snap7.s7protocol import S7Protocol
p = S7Protocol(); p.sequence = 5
print(p.build_userdata_followup_request(3, 2, 1).hex())
# 3207000000060008000400011204114302010a000000

Follow-up request for group 3, subfunction 2, previous sequence 1 (header, parameters, data):

• python-snap7: 32 07 00 00 00 06 00 08 00 04 / 00 01 12 04 11 43 02 01 / 0a 00 00 00
• Real S7-300 with the engineering tool (Wireshark sample s7comm_program_blocklist_onlineview.pcap, frame 98): 32 07 00 00 00 06 00 0c 00 04 / 00 01 12 08 12 43 02 01 00 00 00 00 / 0a 00 00 00

The same twelve-byte, method-0x12 form is what the real tool sends for SZL follow-ups in the other public S7-300 captures (s7comm_reading_plc_status: all 5 follow-ups), and it is what the official native Snap7 client sends. I ran the pinned native client (davenardella/snap7 at 30f37da) against a recording stub peer that answers one fragment announcing more data; its follow-ups are 00 01 12 08 12 44 01 7b 00 00 00 00 for SZL and 00 01 12 08 12 43 02 7b 00 00 00 00 for list-blocks-of-type (parameter length 12, data 0a 00 00 00). The native source agrees (opListBlocksOfType sets Uk = 0x12 and a 12-byte parameter length for every follow-up).

The data section (0a 00 00 00) is identical on both sides; only the parameter block differs. I have not tested whether a real controller tolerates the shorter 0x11 form, so this may work today; it is a deviation from the real tool rather than a confirmed failure.

Suggested change: emit 00 01 12 08 12 <0x40|group> <subfunction> <sequence> 00 00 00 00 with header parameter length 12.

I found this while mapping the lean-s7 conformance corpus onto python-snap7 (lean-s7 itself sent 0x11 for non-SZL follow-ups until it was fixed: gijzelaerr/lean-s7#49). Evidence and the captured vectors: https://github.com/gijzelaerr/lean-s7/blob/main/reports/userdata-continuation-method-2026-10-08.md and https://github.com/gijzelaerr/lean-s7/blob/main/integration/native_client_requests.json.