search

kurenai-ryu / pyzk

The unofficial library of zksoftware the fingerprint attendance machine
GNU General Public License v2.0
37 stars 23 forks source link

real time capture doesn't return the Attendance Object #8

Closed ags02 closed 5 years ago

ags02 commented 5 years ago

Describe the bug while running the live capture feature of the library the,it doesn't return attendance object

To Reproduce I used

  1. Device Name: QF-001 Firmware Version: : Ver 6.60 Aug 23 2014 Platform ZEM600_TFT Device name QF-001 Face Version 7
    1. Ran the sample script for attendance in conn.live_capture(): if attendance is None:

      implement here timeout logic

          print 'No attendance'

      else: print (attendance) # Attendance object

Expected behavior must return the Attendance Object

Capture Data Got this error: 3131343030363400000000000000000000000000000000000f00120b1d0c3703

System (please complete the following information):

Additional context

kurenai-ryu commented 5 years ago

That response seems a correct attendance (for user_id 1140064), could you provide more information:

It always responds with hex code instead of a attendance object? Or it just happened s single time/sometimes (but it gets correctly other times)?

Could you provide a captured data (pcap file?) and the verbose data to compare?

kurenai-ryu commented 5 years ago

ok, on further analysis, the only valid sizes for live data packets are 12 or 36 bytes (yours is a 32 bytes response) the 36 bytes response, most of the time has a filler of 4 bytes (unused or reserved),

if it's an isolated case (it happens from time to time) it means, the socket.recv is reading incomplete data (it's possible, but I never meet with that case)

if it happens all the time, it could be: or incomplete data - broken data - new firmware behaviorwith 32 bytes only response...

anyway, please please, attach a wireshark captured data, that way we can see the data packets, and if they're broken, or 32 bytes only

ags02 commented 5 years ago

ok, on further analysis, the only valid sizes for live data packets are 12 or 36 bytes (yours is a 32 bytes response) the 36 bytes response, most of the time has a filler of 4 bytes (unused or reserved),

if it's an isolated case (it happens from time to time) it means, the socket.recv is reading incomplete data (it's possible, but I never meet with that case)

if it happens all the time, it could be: or incomplete data - broken data - new firmware behaviorwith 32 bytes only response...

anyway, please please, attach a wireshark captured data, that way we can see the data packets, and if they're broken, or 32 bytes only

I think that was only a 32 bytes. I already solved that day and added a valid size for 32 bytes.

kurenai-ryu commented 5 years ago

ok, I pushed also a fix for a 32 byte live packet #