Thanks for that analysis. Without detailed knowledge of the lower layers of these protocols, I couldn't tell if I was hitting some maximum frame size or some other limit. I have a much better idea of where to try and point the finger now :)
The ultimate test will be different hardware I suppose. At some point I will select & order another reader that is more compatible with LibNFC. For now I'll leave my CC with an artificial limit imposed (which I may decrease to your suggestion of 160). I found that the highest I could set this to was 0xF8 (248) before I hit an error. Sam On 21 May 2013 10:13, Francois Grieu <[email protected]> wrote: > On 18/05/2013 21:17, Sam Duke wrote : > > Very well summarised, thank you. My interpretation of the 90 00 was that > it was part of the ISO7816 standard. however 90 00 only seems to appear in > the "status bytes" section of the spec so I am now unsure of what is > generating them. Would you still be suspect of the firmware erroneously > adding this or could it be the initiator of the APDU message (aka the > phone)? > > > The 90 00 makes no sense as part of the ISO 7816 standard at the end of a > Command-APDU message, which is what we are seeing. > > The 90 00 appears in many (but, I realize now, not quite all responses to > ScardControl; this is a strong indication that it is generated NOT as part > of the ScardControl gear in the PC (where it would likely never or always > be present; also it would be unheard of by me that ScardControl adds a > final 90 00 on its own initiative). > My guess is that the 90 00 is generated by some layer of the ACR122U > firmware, as a trailer to any message from the NXP chip to the PC thru > ScardControl. Any other hypothesis (like, the initiator or NXP chip > generates it) seems unlikely to me. > > Now there's the truncation. > It could be by the ACR122U firmware when the NXP chip makes big frames, > and that's my favorite guess. > It could also be in the initiator. That would be unheard of by me. > It could also be an artifact of an incomplete implementation of ISO > 14443-4 chaining, in the initiator (or even the NXP chip). Chaining splits > the Command APDU into two frames, because the ISO 14443-4 makes it > necessary for the initiator to make frames of at most 256 bytes, including > 2-byte final CRC and 1 to 3 bytes header PCB (CID) (NAD), and thus transfer > the C-APDU (of 260 bytes) as two frames; however if that was the cause of > the truncation, it should be to 247 bytes (give or take 1) of incoming > data, not 239, thus I do NOT believe the frame size is the cause of the > truncation. > > The truncation and 90 00 occur at the same point; the simplest assumption > is that there are only one device misbehaving and causing both, and again > that points to the ACR122U firmware. > > As a matter of fact, "long" APDUs have interoperability problems in some > contexts. In my experience, anything with at most 128 bytes of incoming or > outgoing data works reliably almost everywhere; 160 is still very > supported; above that you mileage will vary widely. > > Francois Grieu > > > On 16 May 2013 07:46, "Francois Grieu" <[email protected]> wrote: > >> About the log at >> http://www.sendspace.com/file/ndqiyv >> >> On 15/05/2013 14:02, Ludovic Rousseau wrote >> > 2013/5/15 Sam Duke <[email protected]>: >> >> The trace begins " 00000062 Control RxBuffer: D5 87 00 00 D6 00 02 FF" >> > It is part of the _response_ from the reader. It is not an APDU. >> >> Sam Duke is using an ACR122U in card emulation mode, using ScardControl. >> >> The emulated card receives a message from an initiator, that includes >> >> 1) a TgGetData response header D5 87 00, explained on page 160 of that >> public document on the NXP chip (or a similar one) used by the ACR122U >> http://www.nxp.com/documents/user_manual/141520.pdf >> 2) a Command APDU header CLA/INS/P1/P2/Lc, 00 D6 00 02 FF >> 3) some incomplete incoming data (there should be 255 bytes, there are >> 239) >> 4) 90 00, which is an artifact in all Control RxBuffer in the log. >> >> The truncation could be >> a) by the initiator of the APDU >> b) by NXP chip, but the public document quoted indicates that the size >> limit of of data block following the TgGetData response header is 262 >> bytes. >> c) the ACR122U firmware >> d) whatever chain is involved in the ScardControl >> >> Whatever adds the 90 00 is likely the cause of the truncation. >> My bets are on the ACR122U firmware. >> >> Francois Grieu >> >> _______________________________________________ >> Muscle mailing list >> [email protected] >> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com >> > > > _______________________________________________ > Muscle mailing > [email protected]http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com > > > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com > >
_______________________________________________ Muscle mailing list [email protected] http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
