CoreNFC fails to read NDEF message bigger than 9Kb

Originator:Atrinax
Number:rdar://36809527 Date Originated:24/1/2018
Status:Closed Resolved:17/9/2018
Product:CoreNFC Product Version:11.*.*
Classification:Bug Reproducible:Prior to 12.0
 
Area:
Core NFC

Summary:
CoreNFC fails to read Type 4 NDEF tag with a file bigger than 9 kB failing with “Session is invalidated by user cancellation”, code 200. 
Actually the maximum size iOS is reading without errors is around 8.25Kb, see more in attached file with our research.

Steps to Reproduce:
Attempt to read Type 4 NDEF tag with a payload bigger than 9Kb.
We've used 'Hold - NFC Tag Scanner' from https://itunes.apple.com/us/app/hold-nfc-tag-scanner/id1254631510?mt=8 and our in-house test application.

Expected Results:
Tag is successfully read and delivered to the application.

Actual Results:
CoreNFC fails with “Session is invalidated by user cancellation”, code 200.

Version/Build:
11.0.3, 11.2.5

Configuration:
iPhone 7

Files included:
- Sysdiagnose (tags were scanned at 11:15 – 11:16 (UTC+7)
- Text about our testing of CoreNFC with 16Kb tags

Comments

Alexander Mayatsky

This issue has been verified by the developer as resolved.

By Atrinax at Sept. 21, 2018, 8:44 a.m. (reply...)

Alexander Mayatsky

Can't reproduce, looks like iOS now handles our test NDEF record with 13506 bytes of data. However this fix has no use for us, since we have already launched the app and our updated hardware units to production: https://itunes.apple.com/us/app/lightning-nfc/id1396913827 At this moment we restart the reader session as a workaround and push our payload via multiple NDEF messages.

By Atrinax at Sept. 21, 2018, 8:42 a.m. (reply...)

Apple Developer Relations

Please verify this issue with the iOS 12 GM and update your bug report at https://bugreport.apple.com/ with your results.

iOS 12 GM (16A366) https://developer.apple.com/download/ Posted Date: Sept 17th, 2018

If the issue persists, please attach a new sysdiagnose captured in the latest build and attach it to the bug report.

iOS sysdiagnose Instructions: https://developer.apple.com/services-account/download?path=/iOS/iOS_Logs/sysdiagnose_Logging_Instructions.pdf

For a complete list of logging instructions visit: https://developer.apple.com/bug-reporting/profiles-and-logs/

By Atrinax at Sept. 21, 2018, 8:41 a.m. (reply...)

Text about our testing of CoreNFC with 16Kb tags

Dear Sir or Madam,

We are working on an industrial NFC project and trying to read the NFC Tag Type 4 containing the NDEF file. The tag is our custom device built upon the micro-controller and NFC chip AS3953A. The quotation from the NFC chip data-sheet : "The AS3953A supports ISO 14443A up to Level-4, meaning a contactless smart card or an NFC forum compatible tag (Tag Type 4) can be built". For reading we use iPhone 7 with iOS v.11.0.3. Also tested an iPhone X (same result). We have successfully read our tag and the data bytes transferred to the application are consistent. But unfortunately reading is possible if the NDEF files' length is less than approx. 8.25 kB. In other words we can read an NDEF file with an 8 kB payload but cannot read the file with a 9 kB payload. Meanwhile we need to read files with payload up to 16 kB.

If the file has payload more than (8 kB + 159 Bytes) the iOS terminates reading session with error (sent to our test iOS app) “Session is invalidated by user cancellation”, code 200. Of course there is no "User cancellation" of any kind and we have not found any helpful messages in the Console app either.

We have tested different NDEF files, for example, the NDEF file that contains two records: - record1, well-known URI, length 22 bytes - record2, unknown (byte array), length 8 kB (or more)

or NDEF file that contains: - record1, well-known URI, length 22 bytes _ record2, MIME (application/octet-stream), length N1 kB _ record3, MIME (application/octet-stream), length N2 kB Where (N1 + N2) lower than 8 kB or bigger (8 kB + 257 Bytes and more)

In all cases the reading session is cancelled if the length of an NDEF file is bigger than ~8.25 kB. Also we can inform you that we can successfully read these NDEF files with payloads up to 16 kB using a variety of NFC-capable Android devices.

Can you please explain why the tag reading fails if the NDEF file is bigger than approx. 8.25 kBytes? - Is that an iOS limitation? If yes, then why it is not documented? - Is there a possible workaround for that? - Is there a planned fix for that you are working on?

In addition there is some extra information and our logs.

Our tag sends the following CC file: static const unsigned char fileCC[] = { // first 7 bytes of CC 0x00, 0x0F, // CC file length (big endian) 0x20, // Mapping Version 0x00, 0xF0, // Maximum R-APDU data size 0x00, 0xF0, // Maximum C-APDU data size 

    // 8 bytes of NDEF File Control TLV
    0x04,           // T, 4 - NDEF File Control TLV
    0x06,           // L, 6 for NDEF File Control TLV

    // "block" bytes (6 bytes here, NDEF File Control TLV)
    0xE1, 0x04,    // NDEF File Identifier
    0x80, 0x00,    // NDEF file max length, 32 kB
    0x00,          // NDEF file read access granted
    0xFF           // NDEF File write access denied

};

The device contains the test NDEF file (only first bytes shown below). The remaining bytes of payload are “populated” on the fly and contain the repeating letter A (0xA1).

define LEN_PL (9 * 1024UL) static const unsigned char fileURI[] = { (byte)(( LEN_PL + 7) >> 8), // file length, MSB, (byte)(LEN_PL + 7), // file length, LSB 

    0xC1,   // MB=1, ME=1, CF=0, SR=0, IL=0, TNF=001 (1 - well-known type)
    0x01,   // type length = 1 byte
    (byte)(LEN_PL >>24),      // payload length, MSB
    (byte)(LEN_PL >>16),      //
    (byte)(LEN_PL >>8),       //
    (byte)LEN_PL,             // payload length, LSB
    'U',                      // payload type ('U', URI)
    0x01,   // first byte of the payload, URI Identifier Code (UIC) (0 - nothing, 1 - http://www. , 2 - https://www. , 3 - http:// )
    's','o','m','e','S','i','t','e','N','a','m','e','.','c','o','m','/',
    0xA1   // ’A’, repeats till the end of payload

};

There are two logs extracted from (our) device below.

Note. All numbers (bytes) are hexadecimal.

There is logged history of requests "read binary" commands for NDEF file received from iOS. Logged items are requested "offset" (within NDEF file), requested "length", and an abstract "time" (unit is 0.125 sec). Numbers logged in little-endian format. Below is the dump of that log (with a few comments):

offset length "time"

00 00 02 00 B8 01 - offset 0x0000, length 0x0002, "time" 0x0042 00 00 F0 00 B8 01 F0 00 F0 00 B9 01 E0 01 F0 00 B9 01 - offset 0x01E0, length 0x00F0, "time" 0x0043 D0 02 F0 00 BA 01 C0 03 F0 00 BB 01 B0 04 F0 00 BB 01 A0 05 F0 00 BB 01 90 06 F0 00 BB 01 80 07 F0 00 BC 01 70 08 F0 00 BC 01 60 09 F0 00 BC 01 50 0A F0 00 BC 01 40 0B F0 00 BD 01 30 0C F0 00 BD 01 20 0D F0 00 BD 01 10 0E F0 00 BE 01 00 0F F0 00 BE 01 F0 0F F0 00 BE 01 E0 10 F0 00 BE 01 D0 11 F0 00 BF 01 C0 12 F0 00 BF 01 B0 13 F0 00 BF 01 A0 14 F0 00 BF 01 90 15 F0 00 C0 01 80 16 F0 00 C0 01 70 17 F0 00 C0 01 60 18 F0 00 C1 01 50 19 F0 00 C1 01 40 1A F0 00 C1 01 30 1B F0 00 C1 01 20 1C F0 00 C2 01 10 1D F0 00 C2 01 00 1E F0 00 C2 01 F0 1E F0 00 C2 01 E0 1F F0 00 C3 01 D0 20 31 00 C4 01 - last request, contains "length" = 0x00031 (but expected 0x00F0, because (0x20D0 + 0x00F0) = 0x21CO that is lower than 0x2407 – length of NDEF file body)

There is dump of sent bytes as a response to "read binary" commands (with a few comments) below.

24 07 - response to first reading request (offset 0x0000, length 0x0002, "time" 0x0042 above)

24 07 - response to second reading request (offset 0x0000, length 0x00F0, "time" 0x0042 above), first bytes of NDEF file (length) C1 - flags ("start" + "end" + "Well-known") 01 - length of "type" field (1 Byte) 00 00 24 00 - payload length (big-endian, 9 kBytes) 55 - 'U' (type is "URI") 01 73 6F 6D 65 53 69 74 65 4E 61 6D 65 2E 63 6F - payload bytes, logged first 4 responses (2 + 3 * 0xF0 = 0x02D2 Bytes) 6D 2F 00 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41

41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41

41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41

............. - "middle" responses are not logged due to our hardware limitations (responses contain series of "0x41" bytes)

41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 - logged 2 last requests (0x00F0 + 0x0031 bytes) 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41

41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41

By Atrinax at Jan. 24, 2018, 5:38 a.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!