'Bad 255' Data due to Race Conditions

[sembaye]

Hello, everyone,
I've discovered a bug that shouldn't exist.

The variable requestMaxParallel and maxparallel are used to define the number of parallel jobs in the network. These connection parameters are negotiated with the PLC in the function onPDUReply. That's working as far as I can tell. (see)

This error means that I have set the values from 8 to 1 and still two orders are sent.

The error occurred with a WinAC. Because of "Fast Acknowledge" I have set the values from 8 to 1.

On the following picture you can see a Wireshark section:

Packets 236,237 and 238 show a successful data exchange (including Fast Acknoledge).
Packet 240 shows a transmission request. Packet 242 another one, although maxparallel is set to 1 (!).

The error behavior is that with the received stream data (usually 460 bytes) are not complete.
e. g.:
[2482,147791652 172.20.15.70 S2] Address DB11134, BYTE0.6456 has value
0,..., 0,0,0,0,0,8..., 3,3,32, and quality BAD 255,..., BAD 255, OK, OK, OK, OK, OK, OK, OK, OK, OK, OK, OK, OK, OK, OK

[plcpeople]

Maybe this is failing because there is no code in nodeS7 to deal with COTP fragments. Can you please expand the packet above the "not allowed" one if you still have the wireshark packet capture? I think what we need to do is recognize the fragment as a fragment and store it while waiting for the next fragment, rather than accept it as "bad data" and ask for more data which I think is what is causing the problem.

[sembaye]

Frame 240 - 244:

Frame 240: Read Var

Frame 241: COTP (should be handled correctly in following line )

Frame 242: Read Var (another Job without waiting for answer)

Frame 243: COTP

Frame 244: Response with 3 COTP Segments
I don't think that this is being handled correctly.