Intermittent “Bad Record MAC” after 30 min when polling and subscribing to same tag

[MargoPas]

Steps to reproduce

• Configure the driver to subscribe to tag .
• In parallel, set up cyclic polling (e.g., every 3 s) for the same tag.

Expected behaviour
Driver runs for days without errors (confirmed when running only a subscription or only polling).

Actual behaviour
After ~30 min the log shows

Additional observations

• Pure subscription: stable for ≥2 days.
• Pure polling: stable for ≥2 days.

Combined polling + subscription: fails within 30 min.

Wireshark capture attached (filtered by IP/port).

Looks like a race-condition or buffer overlap when the same tag is accessed through two mechanisms.
Could it be:

Duplicate message IDs causing MAC mismatch?
Concurrent access corrupting the session key?
Driver not handling overlapping sequence numbers?

key_20250814_122751.log

Tls_error Notification + Poll.zip

Any insights or suggested work-arounds (e.g., separate sessions for poll vs. subscribe, throttling poll rate, driver patch) would be appreciated!

[thomas-v2]

If there's a problem in the TLS part, I have to investigate. Except just finding out how the subscription may work in general, I have not been testing around with it. But if you used the sample code with the loop style (which is not a good way), I would use a complete separate TCP connection to the plc for Subscription. That's also the way Siemens is doing this in for example WinCC scada (7.x/8.x), They use one connection for polling, another for variable subscription and if I remember correctly, they use a third connection for alarm subscriptions (alarms generated with ProgramAlarm block from plc program) if this is used.

[MargoPas]

For notifications, a new memory stream was created, which is processed separately. Based on current implementations, testing this project and the HARPOS7 project shows that the system runs stably — more than 9 days without interruption — with parallel subscription and polling of variables (in one session). The same code I used for tls connection.

Regarding connection architecture, in Siemens WinCC SCADA (7.x/8.x), indeed, a separate TCP connection is used for polling, another one for variable subscription, and, if applicable, a third one for alarm subscriptions generated by the ProgramAlarm block in the PLC.

However, in WinCC OA, a single session is used for all three functional purposes (alarm subscriptions, tag subscriptions, and general tag operations).it was more optimal approach to organizing communication with the PLC for me.

[thomas-v2]

I don't know your current implementation, I guess you are creating a different thread for the subscription? With the example code, you can only poll or subscribe, not both, and then this exception should never occur in my opinion.
I think to keep this separated with polling an variable/alarm-subscription, this needs a layer in between, which handles the different PDU types and sends the received information back to the caller.

And WinCC OA I wouldn't use as reference. As far as I know, they don't get access to the Siemens protocol specs, at least at the S7-300/400 times this was the case.