File transfer with SC

[boobika]

Hello,

We are creating a CP in Python, based on this example https://github.com/goToMain/libosdp/blob/master/examples/python/cp_app.py
We are unable to resolve an issue when transferring a file from CP to PD (uploading firmware to the reader).
The problem occurs with active SC during the file transfer attempt.
Without the active SC, the file transfers successfully.

I am also attaching images of the logs, one without SC and one with SC.
In the image with active SC, it can be seen that when the file transfer starts, the PD goes offline and then tries to connect without SC, which fails and displays the error "Invalid SCS type (18)".

File transfer without SC

File transfer with SC

Thank you in advance for your assistance!

Best regards,
Bob

[sidcha]

One part of the issue is that the PD didn't respond to the file transfer command in time (2 lines above the red arrow in your image). You have to debug why this is the case. Do note: if the PD cannot process a command within the 200ms timeframe, it must send a BUSY response not delayed response.

The other part is that the PD does not understand that the CP has gone offline due to this response time out and is attempting to restart a new SC session and hence the subsequent failures. The CP indicates this by resetting the sequence number to 0 which is a cue for the PD to discard it's current SC and start over.

Is the PD firmware based on LibOSDP too?

[boobika]

Unfortunately, the PD firmware is not based on LibOSDP but probably on OSDP.NET. I don't know if I'll be able to debug it in such a way that it doesn't take forever. Everything else works well for us: RFID reading, FW version reading, LED, and buzzer control.
I tried increasing the value of the OSDP_RESP_TOUT_MS constant, but that doesn't seem to be the solution, as the time is always greater than the value of the constant.

Without SC, the start of the transmission is the same: it starts with a timeout, then goes offline, goes online, and the transmission begins. I don't understand why it starts after the timeout? And even the TX-init is not visible in the log afterward.

I am attaching (among other things) my test script for updating the FW, which I based on the test: https://github.com/goToMain/libosdp/blob/master/tests/pytest/test_file_tx.py, but maybe I'm doing something wrong. (I start the file transfer when the RFID is read)

My test code

File transfer Without SC

osdp-trace-cp-pd-1-2024-06-27T14_22_10Z.pcap.txt

File transfer With SC

osdp-trace-cp-pd-1-2024-06-27T14_53_02Z.pcap.txt

[rsgmodelworks]

osdp.net does not implement a PD as far as I know, it's just an ACU. (They're ACU's not CP's.) Some PD's expect file transfers to be only used for firmware update which might mean it's the reader's boot loader that is processing the commands. firmware files are expected to be encrypted so this is secure. A long delay when you initiate a file transfer can be caused by the PD having to switch hardware behavior so as to write to memory devices that are fast-read/slow-write in performance. Check the time to delay listed in the ftstat message. some readers request a significant time delay (7 seconds?) P.s. I myself have not seen a whole built libosdp test program, if one were available someone in the OSDP implementor community could perhaps take a shot at reproducing this issue...

[sidcha]

@rsgmodelworks, Thanks for your clarification. This seems like an odd design; I expect the main firmware to download the firmware file, verify integrity and put it to some place where the bootloader can find it and then enter bootloader.

Nevertheless, if this is how products are implementing it, I'm willing to support it. Which essentially boils down to LibOSDP supporting lack of responses for upto 8 seconds without moving a PD to offline state (as in #186 and maybe even this issue). Also the spec is not super clear about how long a SC session has to be valid IIRC; need to give some though about it.

They're ACU's not CP's

This has come up before :). This project will keep calling the controlling unit as CP. That's how we started and changing it now only leads to more confusion. I can mentally map references made to ACU as CP but that's the how far it will go.

[rsgmodelworks]

I still have scars from the IEC transition, I hear you about calling it a CP. Your expectation as to how devices would be constructed is reasonable, there are devices in the field more primitive than that. My interpretation (I agree this is vague in the spec) is that if you get an osdp_FTSTAT indicating a required delay that the delay applies specifically to the osdp_FILETRANSFER command. My interpretation is that the CP would be expected to continue sending proper secure channel osdp_POLL commands and that the PD would be expected to respond with proper secure channel ACK commands. In libosdp_conformance it uses a crude mechanism (it does a 'sleep' command) so don't take that as a reference point. I have only seen one PD that demands firmware update happen over secure channel, most implementations do a firmware update over an unencrypted link.

[sidcha]

@rsgmodelworks Thanks again. Will take a look at this issue when I get some free time.