Closed xsrf closed 3 months ago
@xsrf Please check if this works for you.
Thx for the fast reply, but nope, now it's completely broken. Now the CP sends a POLL right after the PD replies with the first FTSTAT. My PD doesn't handle the POLL (since it did not obey FtDelay) and everything locks up. Since I can't delay the POLL the same way I delayed the FILETRANSFER, I can't get the transfer to start.
My script is just sitting at OSDP: CP: PD-1: 2024-08-15T09:21:58Z src/osdp_cp.c:686 [DEBUG] CMD: FILETRANSFER(7c) REPLY: FTSTAT(7a)
and I have to kill it via task manager. There is no timeout even after many minutes.
Shouldn't there be a mechanism that will retry a command, re-init the connection or mark the PD as offline?
Edit: cp.get_file_tx_status()
is the call that freezes
Edit2: and with the call to cp.get_file_tx_status()
removed, my loop loops but there is still no additional communication happening (cp.get_event()
just times out every 2s) and no retry or timeout triggered even after minutes.
LibOSDP-3.0.6 master (e8205a0)
Hm, I assumed the PD will still be able to respond to POLL even when file transfer is in delay-wait mode. So what the CP is doing now is to send POLL commands as usual when file transfer is waiting.
Will have to check about the timeouts in cp.get_file_tx_status().
I guess the PD just can't handle anything when switching to firmware update.
However, the FTSTAT
also contains FtAction = 0
which means interleaving is not allowed, so in my understanding, sending POLL
after that may violate the spec.
FTActions in entirely ignored ATM. A bit more work needs to be done to support this in its full glory.
@xsrf I have added some support for this now.
Fair warning: I don't have any device to test this and the integration test suite does not check for these cases; IOW, it's all just eye balling from my side, so please expect rough edges :)
Hmm, I don't see a difference with LibOSDP-3.0.6 master (4225650)
. Still getting the POLL
right after FTSTAT
and then everything hangs. Also cp.get_file_tx_status()
- if added back to the loop - still blocks forever.
Any ideas how I can help debug?
The packet trace file (flags=[LibFlag.CapturePackets]
in PDInfo
), along with a debug level log file (log_level=LogLevel.Debug
in ControlPanel
) should be very helpful.
Also, would prefer to take this discussion to a mail thread (sidcha.dev@gmail.com) and then post the final outcome here.
I'm not sure how to set the flag, but I can still give you the OSDP ethernet capture and full debug log. But there is not really something to see that I haven't already posted. It just stops.
Looking at your commit - is it possible you just inverted the OSDP_FILE_TX_FLAG_EXCLUSIVE
Flag?
Because Bit 0 of FtAction
set/1 means not exclusive (interleave) and not set/0 means file transfer only/exclusive.
In https://github.com/goToMain/libosdp/blob/4225650a4327b22ef3e5841b68a84207987346e2/src/osdp_file.c#L357 you return -1 (don't send any command, wait for me) if the flag is set. But it should be the other way round, shouldn't it?
I'm not sure how to set the flag, [...]
In your script, please apply the following change and invoke it with the option --log-level=7
.
--- /tmp/mod.py 2024-08-16 17:28:56.325901045 +0200
+++ /tmp/orig.py 2024-08-16 17:24:51.437900559 +0200
@@ -86,7 +86,7 @@
## Describe the PD (setting scbk=None puts the PD in install mode)
channel = TCPChannel(args.device, args.port)
pd_info = [
- PDInfo(args.reader, channel, scbk=0),
+ PDInfo(args.reader, channel, scbk=0, flags=[LibFlag.CapturePackets]),
]
## Create a CP device and kick-off the handler thread
You would also need to call cp.teardown()
before exiting the script to finalize the capture file. But feel free to not produce this if you think your capture is sufficiently describing your issue.
Looking at your commit - is it possible you just inverted the OSDP_FILE_TX_FLAG_EXCLUSIVE Flag?
Good catch; indeed, the flag was inverted. Fixed now.
Nice, that fixed it. The CP now waits 6s as demanded by the PD before sending the next FILETRANSFER
and the upload starts properly. I guess I'd consider this fixed. Thx!
>python osdp_fw_update.py 192.168.3.145 1 sq80.osdp --loglevel=7
pyosdp: 2024-08-16T17:01:21Z src/osdp_cp.c:1462 [INFO ] CP Setup complete; LibOSDP-3.0.6 master (99ab23f) NumPDs:1 Channels:1
cp.start()
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:682 [DEBUG] CMD: ID(61) REPLY: PDID(45)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:1229 [DEBUG] StateChange: [ID-Request] -> [Cap-Detect] (SC-Inactive)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'ContactStatusMonitoring' (1/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'OutputControl' (1/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'CardDataFormat' (3/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'LEDControl' (4/2)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'AudibleControl' (2/1)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'TextOutput' (0/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'TimeKeeping' (0/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'CheckCharacter' (1/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'CommunicationSecurity' (0/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'ReceiveBufferSize' (149/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'CombinedMessageSize' (149/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'SmartCard' (0/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'Reader' (0/1)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:459 [DEBUG] Reports capability 'Biometric' (0/0)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:682 [DEBUG] CMD: CAP(62) REPLY: PDCAP(46)
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:1205 [INFO ] Online; Without SC
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:1229 [DEBUG] StateChange: [Cap-Detect] -> [Online] (SC-Inactive)
Loop
OSDP: CP: PD-1: 2024-08-16T17:01:21Z src/osdp_cp.c:682 [DEBUG] CMD: BUZ(6a) REPLY: ACK(40)
File read sq80.osdp
Register file ops True 1 1
OSDP: CP: PD-1: 2024-08-16T17:01:22Z src/osdp_file.c:408 [INFO ] TX_init: Starting file transfer of size: 283464
FW Upgrade started... Reader will reboot when done!
OSDP: CP: PD-1: 2024-08-16T17:01:22Z src/osdp_cp.c:682 [DEBUG] CMD: FILETRANSFER(7c) REPLY: FTSTAT(7a)
OSDP: CP: PD-1: 2024-08-16T17:01:28Z src/osdp_cp.c:682 [DEBUG] CMD: FILETRANSFER(7c) REPLY: FTSTAT(7a)
OSDP: CP: PD-1: 2024-08-16T17:01:29Z src/osdp_cp.c:682 [DEBUG] CMD: FILETRANSFER(7c) REPLY: FTSTAT(7a)
OSDP: CP: PD-1: 2024-08-16T17:01:29Z src/osdp_cp.c:682 [DEBUG] CMD: FILETRANSFER(7c) REPLY: FTSTAT(7a)
OSDP: CP: PD-1: 2024-08-16T17:01:29Z src/osdp_cp.c:682 [DEBUG] CMD: FILETRANSFER(7c) REPLY: FTSTAT(7a)
OSDP: CP: PD-1: 2024-08-16T17:01:29Z src/osdp_cp.c:682 [DEBUG] CMD: FILETRANSFER(7c) REPLY: FTSTAT(7a)
OSDP: CP: PD-1: 2024-08-16T17:01:29Z src/osdp_cp.c:682 [DEBUG] CMD: FILETRANSFER(7c) REPLY: FTSTAT(7a)
OSDP: CP: PD-1: 2024-08-16T17:01:30Z src/osdp_cp.c:682 [DEBUG] CMD: FILETRANSFER(7c) REPLY: FTSTAT(7a)
OSDP: CP: PD-1: 2024-08-16T17:01:30Z src/osdp_cp.c:682 [DEBUG] CMD: FILETRANSFER(7c) REPLY: FTSTAT(7a)
...
Glad things work now. And thanks for putting in the last nail :)
I made a python script to perform a firmware update based on the code from the screenshot in https://github.com/goToMain/libosdp/issues/185#issuecomment-2195026272 and you can see my script in #191
I noticed that the file transfer would just hang after the 2nd packed being sent to the PD. Analyzing the raw data, I noticed that my PD responded to the first
FILETRANSFER
with anFTSTAT
containing a value forftDelay
. But since the CP sent the 2ndFILETRANSFER
packet immediately after theFTSTAT
, the PD kinda locked up and so did my script.After adding a delay to the first
FILETRANSFER
packets (I did this by addingtime.sleep(sender_delay)
tosender_read()
), the transfer works fine.Wireshark Capture
I guess
ftDelay
should be obeyed?Forgot to mention, I'm using the latest release
LibOSDP-3.0.6 master (cf675a0)