goToMain
File transfer with SC
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
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?
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
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...
@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.
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.
@rsgmodelworks Thanks again. Will take a look at this issue when I get some free time.
Is there any hope of resolving my issue with file transfer via secure communication?
Just to clarify, what PD implementation is doing this? Also, would it be possible to capture an OSDPCAP trace and post (some small fragment) here?
@boobika Did you investigate why the PD took that long to respond to those commands? I will fix the CP to go a bit more easy on slow PDs but your problem might me something entirely different. ATM, I'm occupied with another project so it might take a bit longer to implement that fix.
As @rsgmodelworks recommends, please produce captures, but follow this doc (not the OSDPCAP trace) to produce them. We have a more sophisticated tracing method :)
@rsgmodelworks The packet trace is here in this issue below the last two images as downloadable text files. But based on the "Packet trace," I haven't found anything that would help me.
I enable the packet trace differently: by uncommenting the line in the file "libosdp/python/setup.py" and running it, see: https://github.com/goToMain/libosdp/blob/eaacfc6331b4e054f2eda899d7a5bf9246d90d49/python/setup.py#L150
@boobika Sorry I missed those attachments; but the files seem to be corrupted. Can you check and re-upload the files?
tshark: The file "osdp-trace-cp-pd-1-2024-06-27T14_22_10Z.pcap.txt" appears to be damaged or corrupt.
(vwr: Invalid data length 6824001 (runs past the end of the record))
@sidcha @rsgmodelworks Directly here, I could only upload these logs in text format. I'll try to share them now; I have them as .pcap files for Wireshark and also exported as txt.
File transfer Without SC:
File transfer With SC:
After looking at your capture file (with SC), here is what happened (numbers in [] below correspond to the annotations in screenshot above):
The CP first received a Card Read event [1] and then it started a file transfer successfully [2] and then failed to get a response to the second chunk [3] so the CP went offline (notice the >1 second time jump between [3] and [4]). Then when the CP attempted to start a new connection by sending a plaintext command PD_ID [4] with sequence number 0 for which the PD responded with REPLY_ID in secure channel [5] which the CP has already discarded.
The definite issues in your setup is this:
- the PD didn't respond to the file transfer command within 200 milli seconds
- when the sequence number is set to 0, it is supposed to discard all past state (include the secure channel) and start fresh but this feature seems to be missing in the PD implementation
I can potentially fix 1/ but fixing 2/ is up to the PD implementor.
@boobika I have fixed the PD timeout issue. Now LibOSDP will keep a PD online for up to 8 seconds (see #189 for more info).
Closing this ticket as I see nothing more to be done here and haven't heard back from you. Feel free to re-open if you have more info/issues.
@sidcha I have a question. What program was used to analyze the OSDP protocol in your above screenshot?
It’s WireShark. See https://libosdp.sidcha.dev/libosdp/debugging#wireshark-payload-dissector to know more.