Closed broth-itk closed 4 years ago
kleest
commented
5 years ago We are currently working on relaying NFC traffic over the network. This setup creates a delay in communication and since the introduction of a 500ms timeout the relay has stopped working. Due to legitimate applications taking longer than 500ms, we support increasing the default timeout or having no default timeout altogether, in addition to the configurable value.
broth-itk
commented
5 years ago Please check out the other pull requests. I haven't checked if they were merged. There is a function which allows the timeout to be configured. 500ms was not chosen by me but taken from the previous source code.
On 07/05/2019 19:25, Steffen Klee wrote:
We are currently working on relaying NFC traffic over the network. This setup creates a delay in communication and since the introduction of a 500ms timeout the relay has stopped working. Due to legitimate applications taking longer than 500ms, we support increasing the default timeout or having no default timeout altogether, in addition to the configurable value.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nfc-tools/libfreefare/pull/101#issuecomment-490173010, or mute the thread https://github.com/notifications/unsubscribe-auth/AAR7K5EX2UXLT3SWBCT62PDPUG3PXANCNFSM4GSPFPZA.
manu0401
commented
5 years ago Steffen Klee notifications@github.com wrote:
we support increasing the default timeout or having no default timeout altogether, in addition to the configurable value.
Use an increased timeout if that is useful, but please do not default to no timeout. libnfc has some workaround for the pn533 toggle bit bug, but it can only be used if we do not get stuck on an infinite timeout.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
kleest
commented
5 years ago @broth-itk I haven't found one that makes the timeout configurable. Which pull requests do you mean? Can you point me in the right direction?
@manu0401 I understand the problem of infinite blocking and agree with an increased timeout, but the current situation is that a different timeout currently requires a custom build of libfreefare. That's why I drew attention to this unmerged PR.
broth-itk
commented
5 years ago @Steffen: Pull request #101 is fine, see freefare_set_tag_timeout
I don't know why these pull requests are deserted.
@manu0401: Is there anything I can do in order to get them into HEAD anytime soon?
On 09/05/2019 01:11, Steffen Klee wrote:
@broth-itk https://github.com/broth-itk I haven't found one that makes the timeout configurable. Which pull requests do you mean? Can you point me in the right direction?
@manu0401 https://github.com/manu0401 I understand the problem of infinite blocking and agree with an increased timeout, but the current situation is that a different timeout currently requires a custom build of libfreefare. That's why I drew attention to this unmerged PR.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nfc-tools/libfreefare/pull/101#issuecomment-490684532, or mute the thread https://github.com/notifications/unsubscribe-auth/AAR7K5DIE3RMBUECSVN746TPUNMZRANCNFSM4GSPFPZA.
--
Roth ITK Consulting GmbH Tumblingerstr. 23 80337 München Germany
Fon: +49 89 4161450-10 Fax: +49 89 4161450-99 Email: broth@roth-itk.de Web: http://www.roth-itk.de
Geschäftsführer: Bernhard Roth HRB 174971, Amtsgericht München USt-ID: DE261708872
smortex
commented
4 years ago @darconeous, :+1: for "Squash and merge". GitHub does a good job for keeping correct attribution for the generated commits.
Previously none or an arbitrary timeout (500ms) was used. This can be useful but causes some issues when operations take longer (frequently during mifare_desfire_format_picc)
Following updates have been made:
Background:
I am using the lib to personalize Desfire tags. I noticed failed format operations with the latest git version. The tag was left in an useless bricked state, not able to communicate anymore.
When a timeout happens, possibly libnfc switches off the RF field. This caused the PICC to enter a "failed" state. When trying to format it again, there was always a timeout when selecting the tag.
During my tests, I discovered that increasing the timeout helped to get the tag back to life. Possible cause: When selecting the PICC, it might detect a corrupted filesystem and format itself again. As format took quite long, the timeout kicked in.