1

When I put SIII (Android 4.3) on ACR122U NFC reader the LED keeps blinking green. When I put Samsung S4 (Android 4.3) LED turns green till the time phone is on the reader. In both the cases NFC is turned on and device is in unlocked state. This behaviour translates into frequent disconnections in SIII and a stable connection on S4. Why two phones behave differently? I am aware of the fact that two phones have NFC chipsets from two different vendors namely NXP and Broadcom.

My question is what is the source for such inconsistent behaviour among these devices?

Another question is why does phone give an ATR at all?

Michael Roland
  • 39,663
  • 10
  • 99
  • 206
Sunita
  • 336
  • 2
  • 18
  • What mode are you using? Are the phones used in reader/writer mode, card emulation mode or peer-to-peer mode? – Michael Roland Feb 13 '14 at 15:24
  • I am simply connecting the reader with default settings, no PC application. No additional app is installed on phone and only setting changed is NFC on. – Sunita Feb 13 '14 at 16:01
  • So you are using one NFC device (the ACR122U) in reader/writer mode and the second NFC device (Android phone) in peer-to-peer mode (or are you using an NFC-enabled SIM card? In that case at least the S4 will also activate card emulation mode...) While peer-to-peer mode (under certain conditions) will look like a contactless card to a reader, you can't expect them to communicate with each other due to the different operating modes and protocols. So what you are trying to do does not make much sense (except for the case with the NFC-enabled SIM card) and won't lead to any useful results. – Michael Roland Feb 14 '14 at 06:22
  • We're not using NFC SIM cards. The real problem comes when I use PC/SC library to send TginitTarget command to reader's NFC controller to put it on PICC emulation mode. Algorithmically we select a reader then connect to reader and send controller command wrapped with special APDU prescribed by ACR122U. In case of S4 connect to reader succeeds since phone gives ATR and connection remains stable while in S3 connection fails and TginitTarget fails with 6300. https://code.google.com/p/ismb-snep-java/issues/detail?id=1 – Sunita Feb 14 '14 at 07:08
  • So could you explain what exactly you are doing now? If you use `TgInitAsTarget`, then you are **not** using the ACR122U in reader/writer mode but in card emulation mode. In that case, the Android device would operate in reader/writer mode. Could you also explain why you believe that the phone sends an ATR? (Btw. there is no ATR involved in either case as an ATR is specific to contact smartcards.) – Michael Roland Feb 14 '14 at 10:38
  • We are selecting reader and sending TgInitAsTarget wrapped in special APDU(FF 00 00 00 XX) in order to exchange set of APDUs from phone(reader mode) and emulated card . TgInitAsTarget does not succeed if S3(4.3) is put ACR122U reader(LED is blinking green) and no intent is received in Android app to start communication with IsoDep. In case of S4(4.3) this does not happen and we are able to successfully exchange APDUs between emulated card and Android app. You are right ATR is wrong term in context of contactless cards, I'm not sure if they call it ATS. – Sunita Feb 14 '14 at 13:50
  • I just tried card emulation using a Galaxy S3 (4.1.2) together with an ACR122U in card emulation mode and it works as expected. – Michael Roland Mar 01 '14 at 19:00
  • Michael it would help a lot if you could post your APDU sequence here. Additionally, if you put your phone on ACR122U (without running any host application on PC) does reader's LED turn green and stays green until you remove phone? – Sunita Mar 03 '14 at 09:07
  • See this answer: http://stackoverflow.com/questions/21051315/nfc-acr122-tginitastarget-initiator-releasing-target/21107403#21107403 – Michael Roland Mar 04 '14 at 07:34
  • We tried exactly the same APDU sequence but PC/SC function ScardConnect(http://msdn.microsoft.com/en-us/library/windows/desktop/aa379473%28v=vs.85%29.aspx) fails in the very first command as it can not detect a card on top of a reader. It works fine if we put S4(4.3) works but not if S3(4.1.2). – Sunita Mar 07 '14 at 05:13

1 Answers1

3

The command sequence for software card emulation using an ACR122U/PN532 can be found in this answer.

In addition to that, there are different versions of the ACR122U:

  • Some always indicate the presence of a smartcard. In that case it is possible to connect to the "simulated" card using

    // SCardConnect with SCARD_SHARE_SHARED, SCARD_PROTOCOL_ANY
Card card = cardTerminal.connect("*");
CardChannel cardChannel = card.getBasicChannel();

    After that, PN532 commands can be sent using APDU wrapping:

    > FF000000 Lc PN532-COMMAND
< PN532-RESPONSE 9000

    with the cardChannel.transmit method:

    CommandAPDU commandAPDU = ...
// SCardTransmit
Response responseAPDU = cardChannel.transmit(commandAPDU);

  • Other versions of the ACR122U do not always "simulate" the presence of a smartcard. Instead they automatically poll for contactless cards and only indicate card-presence if an actual card is presented to the reader. In that case using cardTerminal.connect("*"); would be only possible if there is an actual card present. However, this is typically not the case in situations where the ACR122U is used in software card emulation mode. In that case it is still possible to establish a connection to the reader using direct mode

    // SCardConnect with SCARD_SHARE_DIRECT
Card card = cardTerminal.connect("direct");

    After that, the same APDU-wrapped PN532 commands can be exchanged with the reader using escape commands (you might want to check the manual if the escape command is correct for your reader version):

    final int IOCTL_SMARTCARD_ACR122_ESCAPE_COMMAND = 0x003136B0; //IOCTL(3500) for Windows
//final int IOCTL_SMARTCARD_ACR122_ESCAPE_COMMAND = 0x42000DAC; //IOCTL(3500) for Linux
byte[] commandAPDU = ...
// SCardControl
byte[] responseAPDU  = card.transmitControlCommand(IOCTL_SMARTCARD_ACR122_ESCAPE_COMMAND, commandAPDU);
Community
  • 1
  • 1
Michael Roland
  • 39,663
  • 10
  • 99
  • 206
  • This detail is very helpful and informative. Just one thing to note, We are using single ACR reader and host application but two different phones are producing different results.Now, I do understand there's no need of putting the phone on reader to set it into card emulation. – Sunita Mar 07 '14 at 08:49
  • The difference is is related to how a phone reacts to the reader's polling commands. If the phone respondes to the polling with something that the reader interprets as the detection of a smartcard, the reader will show an "inserted smartcard" and it will become possible to connect to the reader using `cardTerminal.connect("*");`. – Michael Roland Mar 07 '14 at 09:22
  • We tried card.transmitControlCommand(IOCTL_SMARTCARD_ACR122_ESCAPE_COMMAND, commandAPDU) in "direct" mode as our version of reader does not simulate a card. We notice that card.transmitControlCommand(IOCTL_SMARTCARD_ACR122_ESCAPE_COMMAND, commandAPDU) returns 0x9900 when no card is present but returns D58D xx ... 9000 when card is present. I want to put the card reader in card emulation mode without putting the phone on the reader. Here commandAPDU is TagInitAsTarget FF00000027D48C05040012345620000000000000000000000000000000000000000000000000000000000000 – Sunita Mar 28 '14 at 10:54
  • That's odd. Do other commands besides TgInitAsTarget (e.g. Read/WriteRegister) work? – Michael Roland Mar 28 '14 at 11:24
  • Everything worked but we had to put phone on the reader to perform successful TgInitAsTarget. – Sunita Apr 09 '14 at 05:47