android — Невозможно отправить большие команды APDU с помощью libnfc с помощью nfc_initiator_transceive_bytes ()
Я пытаюсь построить оболочку C ++ вокруг libnfc установить связь между моим Android и PN532 RFID модуль.
Это мне очень помогло: http://nfc-tools.org/index.php/Libnfc:APDU_example
Этот код предназначен для отправки команды APDU, где тело содержится в message (Я не отправляю байты заголовков и т. Д.) И прочитал ответ в response,
Проблема: Если message превышает 262 персонажи тогда я получаю переполнение буфера обнаружено ошибка. В противном случае это работает на отлично. Я даже не думаю, что ошибка выдается библиотекой NFC.
bool send(const std::string &message, std::string &response){
std::vector<uint8_t> apduCmd(message.begin(), message.end());
uint8_t *capdu = &apduCmd[0];
size_t capdulen = apduCmd.size();
uint8_t rapdu[10];
size_t rapdulen = 10;
// BUFFER OVERFLOW HERE
int res = nfc_initiator_transceive_bytes(m_nfcDevice, capdu, capdulen, rapdu, rapdulen, 500);
if (res<0) {
return false;
}
if(res<2 || rapdu[res-2] != 0x90 || rapdu[res-1] != 0x00){
return false;
}
// byteArrayToString omitting the last two bytes
response = byteArrayToString(rapdu, 0, res-2);
return true;
}
Решение
Ограничение в 262 байта является жестким ограничением, наложенным чипом NFC PN532. Это максимальный размер необработанных данных, которые могут быть отправлены (и получены) в одной команде InDataExchange. libnfc явно устанавливает этот предел для метода nfc_initiator_transceive_bytes() (увидеть определение abtCmd в pn53x_initiator_transceive_bytes() и определение PN53x_EXTENDED_FRAME__DATA_MAX_LEN).
Что вы можете сделать, чтобы преодолеть это ограничение, так это составить свои собственные блоки ISO / IEC 14443-4 (используя InCommunicateThru, т.е. nfc_initiator_transceive_bytes() с m_nfcDevice->bEasyFraming выключен. Хотя каждый кадр будет по-прежнему ограничен 263 байтами (PN532 фактически разрешает 264 байта для InCommunicateThru, но libnfc, по-видимому, ограничивает это до 263 байтов), вы можете затем упаковать свои APDU расширенной длины в несколько I-блоков ISO / IEC 14443-4. Однако вам придется самостоятельно обрабатывать все кадры ИСО / МЭК 14443-4 (это означает, что вы также должны позаботиться о получении подтверждений и т. Д.)
Наконец, поскольку другой конечной точкой связи является устройство Android: многие устройства Android не поддерживают APDU расширенной длины. Следовательно, даже если вы отправляете более длинные APDU, вы не сможете получать и обрабатывать их на стороне Android. Также имейте в виду, что вам следует отправлять надлежащие APDU, соответствующие структурам, определенным в ИСО / МЭК 7816-4 (т.е. APDU с действительными полями заголовка и длины), в противном случае вы можете столкнуться с проблемами при обращении к некоторым устройствам.
Другие решения
Других решений пока нет …