Topic: Hardware poll for desfire?

Dear all,

What is the recommended way to poll for desfire cards? I prefer to use the libnfc nfc_initiator_poll_target function, as it uses hardware polling and is presumably more efficient, but it doesn't seem to play nice with Desfire cards.
My goal is to use desfire cards to get access to a room, so the process needs to be fairly fast. I'm using a PN532 based reader connected to a raspberry pi.

For Mifare classic cards I use the following  (in pseudocode):

nfc_initiator_poll_target(..., candidate)
tag = freefare_tag_new(candidate)

This works well, and is fast (card needs to be present for less than 1s)

For Desfire cards, I tried the following:

1. With hardware polling

nfc_initiator_poll_target(..., candidate)
tag = freefare_tag_new(candidate)

Hangs on desfire_connect until I remove and replace the card, so is not usable

2. With repeated calls to freefare_get_tags

while (1) {
    tags = freefare_get_tags (device);
    if (! tags[0})
    mifare_desfire_connect (tags[0]);

This works, but it very slow and CPU intensive

3. Combined hardware polling and call to freefare_get_tags

nfc_initiator_poll_target(...)     // ignore result
tags = freefare_get_tags (device);
mifare_desfire_connect (tags[0]);

This works, but is way too slow to be usable, requires the card to be present for more than 3s

Any advice is appreciated.

Please note that I simplified the code above as much as possible, and I'm aware it doesn't work like this exactly. I'm happy to provide the full code if that's helpful.

best regards,

Re: Hardware poll for desfire?


The first scenario is the good one, if desfire_connect hangs then its a bug.

Please report an issue in the issues tracker at :

Of course, you can fork it then patch it and push request, we will be happy to have a look then merge it.

Some ideas to fix it:  desfire_connect may hangs due to a re-selection while not relevant, in this case you can try to put nfc_initiator_target_is_present() in libfreefare.

Romuald Conty