Блог

Главная - Вопросы по программированию - NFC ADPU CLA = 0x03, что это значит?

NFC ADPU CLA = 0x03, что это значит?

#android #nfc #smartcard #rfid #apdu

#Android #nfc #смарт-карта #rfid #apdu

Вопрос:

Я настраиваю эмуляцию метки NFC типа 4 с помощью микроконтроллера и интерфейса NFC. Первый шаг — просто отобразить текстовое сообщение на смартфон с поддержкой NFC, после отправки сообщения NDEF на устройство чтения NFC (телефон) оно отображается как ожидалось, но затем устройство чтения отправляет дополнительную команду ADPU:

 0x02 PCB
0x03 CLA
0xB0 INS
0x00
0x00
0x01

Что означает CLA = 0x03?

Означает ли это, что что-то пошло не так с последним ответом-ADPU?

Чего теперь читатель ожидает от тега?

Я проверил ISO7816, но не нашел там объяснения

Я ожидал бы, что считыватель должен освободить тег после получения окончательного сообщения NDEF, или я должен просто перевести свой интерфейс NFC в режим ожидания?

Спасибо за информацию, Андреас

         case AMS_WF_NDEF_READ_REQ:
            if ((nBytesInFIFO==6)
            amp;(fifoData[0]==0x03) // PCB header byte
            amp;(fifoData[1]==0x00) // ATPDU: CLA instruction class
            amp;(fifoData[2]==0xB0) // ATPDU: INS instruction code (B0=SELECT-FILE, see ISO7816, table-11)
            amp;(fifoData[3]==0x00) // ATPDU: P1  instruction parameter #1, P1 and P2 are the offset for reading
            amp;(fifoData[4]==0x02) // ATPDU: P2  instruction parameter #2
            amp;(fifoData[5]==0x0A))// ATPDU: Lc  Length of data field in the reply
            {
                sprintf_P(str,PSTR("NDEF-RD-RQSTn"));  uart_puts(str);
                ams_resp(0x0A 3,        // num parameter, depends on the data length info from reader
                         0x03,          // PCB header
                         0xD1,          // NDEF header 
                         0x01,          //      type length
                         0x06,          //      payload length
                         0x54,          //      type, for example: 'T'=Text
                         0x02,          //
                         0x65,0x6E,     //      language code, for example: "en"
                         0x6F,0x6B,0x0A,//      payload
                         0x90,0x00);    // OK
                ams_state=AMS_WF_PCD_SEL_BY_DF_NAME; // back to initial state
            }

Комментарии:

1. Вы уверены, что байт CLA равен 0x03, а не 0x00 (и что при получении этой команды не было ошибки CRC)? Если бы это было 0x00, полученная вами команда имела бы смысл и указывала бы на то, что вы используете устройство Android с чипсетом NFC от Broadcom / используете реализацию libnfc-nci.

2. Я уверен, что ошибки CRC не было, потому что байт PCB указывает на обычный I-блок, и я несколько раз проверил последовательность, и, похоже, это CLA, на самом деле CLA = 3 означает, что должен быть открыт другой логический канал, но моя эмуляция тега не подготовлена для этого, когда я отправляю код ошибки в ответе, считыватель продолжает повторять попытку. на самом деле это чип broadcomm в Galaxy-S4. обычно считыватель должен отправить команду отмены выбора тега после получения содержимого NDEF. возможно, чип broadcomm какой-то «особенный», и я должен попробовать его с другим смартфоном.

3. смотрите мой обновленный ответ о том, почему CLA равен 0x03.

Ответ №1:

Получаемая вами команда 03 B0 00 00 01 является командой READ_BINARY (выдается по логическому каналу 3) для последнего выбранного файла. Это типичное поведение NFC-стека libnfc-nci (и, следовательно, присутствует на всех устройствах с набором микросхем Broadcom NFC). Стек NFC пытается прочитать один байт файла NDEF (тега NFC Forum Type 4) с помощью этой команды. Известно, что это мешает работе многих приложений, поскольку это может произойти в середине других команд, отправляемых приложением.

В NFC-стеке libnfc-nci (неправильно) реализована отправка команды READ_BINARY ( 00 B0 00 00 01 ) по базовому каналу (логический канал 0) в качестве механизма проверки наличия, чтобы определить, все еще существует тег или он был удален из устройства чтения NFC. Устройства на базе libnfc-nxp (чипсеты NXP) корректно используют механизм проверки наличия, описанный в ISO 14443-4. Это известная и не исправленная ошибка довольно давно: проблема № 58773.

Чтобы преодолеть возникающие проблемы такого типа «проверки присутствия», в более новых версиях libnfc-nci было реализовано несколько альтернативных подходов для проверки присутствия:

  • READ_BINARY на канале 0 00 B0 00 00 01 : это значение было по умолчанию для первых поколений libnfc-nci и использовалось на большинстве устройств с чипсетом Broadcom вплоть до Android 4.4.4.
  • READ_BINARY на канале 3 03 B0 00 00 01 : это было реализовано как альтернатива отправке команды READ_BINARY на канале 0. Похоже, что идея, стоящая за этим, заключалась в том, чтобы избежать помех любой текущей связи по каналу 0. Однако, из того, что я обнаружил, кажется, что канал 3 никогда не открывается (ни явно через MANAGE_LOGICAL_CHANNEL, ни неявно через команду SELECT). Следовательно, это все еще может вызывать проблемы на некоторых (многих?) картах.
  • ISO/IEC 14443 деактивация и повторная активация карты.
  • Проверка наличия на соответствие стандарту ISO / IEC 14443 с использованием пустых I-блоков.

Механизм проверки наличия настраивается через конфигурационный файл /system/etc/libnfc-bcrm.conf. Смотрите libnfc-bcrm.conf, начинающийся со строки 250.