Tool presumes wrong sequence number after exchange in deactivated communication mode

[PiotrBzdrega]

Hi,
I use version v1.0.1
I'm aware that it is not the final version and even maybe such functinality is intentional,
just wanted to share my findings regarding #57 .

Issue (potential)

When tool works in deactivated communication mode, response for initiated request from tool is seen by device as succesfull since connection is up and kernel receives data, does not matter that buffer is not read on application layer.
In consequences, device increases sequence number for this exchange, but tool does not (wrongly assumes that device did not succeed with response message)

I think it is good case for testing sequence mismatch, but to let the device know about "real" communication problem i think it would be valid to consider partial socket shutdown for writing, so device will not be able to write response and will close connection faulty.

On the other hand when exchange in deactivated communication mode is initiated by device, tool close connection what is perceive by device as failure and sequence number is not incremented on both sides

Steps to reproduce

• Start Server
• Execute standard handshake with device (Register Device and Confirm Registration)
• Toggle Activate communication interruptions button to disable communication
• Press Get Status to send request to the device (seq 42491) (device respond with incremented seq 42492, but tool does not log it)
• Press (second time) Get Status to send request to the device (seq 42491) (device notice wrong sequence number mismatch and prepare request message for it)

Logs

Server is listening on address: /172.20.73.33:12123
Accepted connection from /172.20.73.31:59096
< Received:
< Seq: 42490 - Len: 34
< registerDeviceRequest {
<   deviceIdentification: "29665761"
<   ipAddress: "172.20.73.31"
<   deviceType: SSLD
<   hasSchedule: false
<   randomDevice: 55216
< }
> Sent:
> Seq: 42490 - Len: 41
> registerDeviceResponse {
>   status: OK
>   currentTime: "1761915136146"
>   randomDevice: 55216
>   randomPlatform: 38794
>   locationInfo {
>     timeOffset: 60
>     latitude: 52260857
>     longitude: 5263121
>   }
> }
Accepted connection from /172.20.73.31:58466
< Received:
< Seq: 42491 - Len: 11
< confirmRegisterDeviceRequest {
<   randomDevice: 55216
<   randomPlatform: 38794
< }
> Sent:
> Seq: 42491 - Len: 15
> confirmRegisterDeviceResponse {
>   status: OK
>   randomDevice: 55216
>   randomPlatform: 38794
>   sequenceWindow: 1
> }
> Sent:
> Seq: 42491 - Len: 2
> getStatusRequest {
> }
Not listening for a response because the communication is disabled
> Sent:
> Seq: 42491 - Len: 2
> getStatusRequest {
> }
Not listening for a response because the communication is disabled
Accepted connection from /172.20.73.31:34886
< Received:
< Seq: 42493 - Len: 51
< eventNotificationRequest {
<   notifications {
<     event: SECURITY_EVENTS_OUT_OF_SEQUENCE
<     description: "Sequence Number Mismatch "
<     timestamp: "20251031135927"
<   }
< }
Not sending a response back, because the communication is disabled
Accepted connection from /172.20.73.31:40748
< Received:
< Seq: 42493 - Len: 51
< eventNotificationRequest {
<   notifications {
<     event: SECURITY_EVENTS_OUT_OF_SEQUENCE
<     description: "Sequence Number Mismatch "
<     timestamp: "20251031135927"
<   }
< }
Not sending a response back, because the communication is disabled
Accepted connection from /172.20.73.31:59542
< Received:
< Seq: 42493 - Len: 51
< eventNotificationRequest {
<   notifications {
<     event: SECURITY_EVENTS_OUT_OF_SEQUENCE
<     description: "Sequence Number Mismatch "
<     timestamp: "20251031135927"
<   }
< }
Not sending a response back, because the communication is disabled

[smvdheijden]

Hi,
The current behavior is indeed good for testing sequence number mismatches. But as you've mentioned, it will not be detected by the device, and as such the sequence number on the device will be increased. We have created an item on our backlog to check if we can add an option to immediately close the connection after sending the command, preventing the device to successfully send a response.

We've noticed that the test tool itself does not yet verify the sequence number in incoming messages against the sequence window, so we've created a backlog item for this as well.

Furthermore we've noticed the sequence window returned by the test tool in the registration confirmation response is very small, this will be increased to a more realistic value in an upcoming pull request.