title: What does APDU response 910B mean for a DESFire EV2 card?
body: <p>I am programming DESFire EV1 and DESFire EV2 cards via DESFire commands as wrapped APDUs. When a card is presented I use the GetVersion command to fetch the UID (which I then use to look up card history and to diversify keys). I send this command to get the card version info:</p>
  
  <pre><code>90 60 00 00 00
  </code></pre>
  
  <p>Normally I get a response of some bytes plus <code>91 AF</code> indicating that there is more information to request which we repeat etc as per docs. This works nicely for DESFire EV1 and DESFire EV2 cards until we use them in an OMNIKEY 5x21 reader (readers are in two models of HID card printers, HDP5000 and DTC4500e). When we do that we get the response <code>91 0B</code>
  and no data - <strong>but only from the EV2 cards</strong> we see no issues with EV1. I do not see this response documented anywhere and I'm unclear as to what it might mean.</p>
  
  <p>To re-iterate - we only see this in the omnikey readers with DESFire EV2 cards. DESFire EV1 cards do not do this and we don’t see this at all with other card readers (so far).</p>
  
  <p>We have had some limited success in rotating the cards. One of our remote engineers had success with a particular orientation of the cards which suggests there is some EM/range/antenna issue but QA and production can not reproduce this at all so far.</p>
  
  <p>I also posted this question to the NXP forums with no response. This post has a little more detail.</p>
  
  <hr>
  
  <p><strong>Update in 2020</strong>: I just had the pleasure of encountering <code>91 0B</code> as a response from a Desfire card again, searching for the error and finding my old post from years ago. The circumstances are completely different but I can now add this much: a response of <code>91 0B</code> means:</p>
  
  <blockquote>
    <p>Command is received in a state where this command is not supported, or a totally unknown command is received.</p>
  </blockquote>