Closed shombre closed 8 years ago
Thanks for this. After your previous comment on the CID bit handling I found and fixed that one. Could you explain why do you think that PrologueLength
is incorrect? As far as I can see it is set correctly at lines 1506..1512? The change you introduce seems to simply duplicate that.
Did not see that you already fixed the CID bit. With this your implementation should work fine. : )
Could you explain why do you think that PrologueLength is incorrect?
1506..1512 calculates the PrologueLength
of the readers request. At 1528..1540 you need the PrologueLength
of the cards response.
The card may
PrologueLength
(see #4) It's a matter of taste, but imo it does not make sense to build a new prologue while copy the length from the request.
I can see your point.
The thing is, though, that I cannot see a case in which the PCD request prologue length would not be equal to the PICC response prologue length. The standard specifically states that whenever the PCD sends CID and/or NAD, those shall be used in the response as well. Thus my assumption. If we decide that those two lengths may not be equal, then buffer handling gets quite a bit involved as we have to pass two pointers to MifareDesfireProcess()
and have additional fun there...
I think we should have separate input/output buffers anyway for ISO 14443-4 to support transparent retransmission, but that's a separate concern.
agree! i close this as the main issue is fixed by commit c0765c51701fe67ccc6d7c1c07519878ad525297.
alternative to #1. this fixes a wrong handling of the prologue in iso14443-4 frames.
PrologueLength
was not correct when CID is not usedCID-bit
in PCB of response was not set when CID is used