Hello,

For an S7-1200 (v2.2), is it safe to say that the S7commPlus protocol follows a similar structure to the S7comm?

In other words - for data transfer between the S7-1200 and an HMI, can I say that the S7commPlus protocol follows the general S7comm structure shown here:

1. Establish a connection using a 3-way TCP handshake (port 102)

2. COTP request & confirm (connect on ISO layer)

3. Establish a connection on the S7comm layer

4. HMI sends requests for commands / functions to the PLC using a master-slave communication model

5. Termination of the connection using a 3-way TCP handshake

Hello AutoGen_8233593

Which HMI do you use?

If you use Siemens HMIs they have already a S71200/1500 communication channel integrated.

Here are some general useful information:

https://support.industry.siemens.com/cs/ww/en/view/109479986
https://support.industry.siemens.com/cs/de/en/view/109478253
https://support.industry.siemens.com/cs/de/en/view/109476062

Bye Murof

AutoGen_8233593

Hello,

For an S7-1200 (v2.2), is it safe to say that the S7commPlus protocol follows a similar structure to the S7comm?

In other words - for data transfer between the S7-1200 and an HMI, can I say that the S7commPlus protocol follows the general S7comm structure shown here:

1. Establish a connection using a 3-way TCP handshake (port 102)

2. COTP request & confirm (connect on ISO layer)

3. Establish a connection on the S7comm layer

4. HMI sends requests for commands / functions to the PLC using a master-slave communication model

5. Termination of the connection using a 3-way TCP handshake

For your controller and firmware version, It's in general as you've described. Only the COTP payload is different between S7comm and S7commPlus, and they have almost nothing in common.

Newer firmware controllers allow TLS authentication / encryption, but this doesn't happen on TCP layer, but on the COTP communication layer (COTP payload is encrypted).

Hi Thomas,

1) You mean the COTP payloads have nothing in common? Or the S7comm and S7commPlus have nothing in common?

2) If an S7-1200 is operating under v2.2, does it only strictly talk via S7comm and not S7commPlus?

Thanks!

AutoGen_8233593

1) You mean the COTP payloads have nothing in common? Or the S7comm and S7commPlus have nothing in common?

The COTP payload is the next protocol layer. It's either S7comm or S7commPlus. And they have nothing in common.

AutoGen_8233593

2) If an S7-1200 is operating under v2.2, does it only strictly talk via S7comm and not S7commPlus?

Thanks Thomas - appreciate your expertise in this (including the dissector I saw you have developed).

One more follow-up regarding this, would an SZL read request be applicable / work with an S7-1200 (firmware version 2.2)?

I know SZL typically applies to an S7-300 or S7-400 but if the S7comm generally applies to other S7 models - I wonder if SZL read falls under the 'basic variable access services of the protocol' you had mentioned in your response.

AutoGen_8233593

One more follow-up regarding this, would an SZL read request be applicable / work with an S7-1200 (firmware version 2.2)?

I know SZL typically applies to an S7-300 or S7-400 but if the S7comm generally applies to other S7 models - I wonder if SZL read falls under the 'basic variable access services of the protocol' you had mentioned in your response.

From what I've seen, SZL requests are not answered. If haven't tested if there are any with a response.

That's the only reason you couldn't connect an old WinCC with the classic S7 channel (before the 1200/1500 was added) to a 1200 or 1500, even if Put/Get was enabled. Because WinCC requests some SZL sets from the Plc, regarding communication parameters. If the Plc doesn't answer them, WinCC stops the data exchange.

Ah interesting.

I actually used a cybersecurity tool that can simulate SZL read requests and there were actually successful responses from the S7-1200 (v2.2). But this might not represent a practical use-case when using a WinCC I guess like you were mentioning.

I'm happy to share the PCAPs if you're interested.

Sounds good - thanks for looking at that.

From my PCAPs, I noticed that ID 0x001c and 0x0d91 are failing (in case you every come across an issue with it). Cheers.