libnfc | allows userspace application access to NFC devices

The comment from Matthew Watson and the link he shared had the correct answer!

So I modified the pinvoke line like this:

Web NFC is supported on Android only as of February 2021. See https://web.dev/nfc/

The WebUSB error suggests you're requesting an interface that implements a protected class (among those below):

Answer

Update 2020mar29hkt2040

Part 1 - libnfc v1.17 I2C config tested OK

The OP has no luck in testing libnfc I2C mode and SPI mode. I tried I2C mode and found everything OK. I guess the OP has not set the config file, or has not set "auto scan = true". See my example libnfc171 config file in Appendix A. PS - (1) My NFC reader can detect a tag without any problem. (2) I am using Rpi4B buster 2020mar13.

Part 2 - Now testing SPI mode 2020mar29hkt2044

Sunfounder config instructions recommends lowering SPI speed 50kHz. So I have changed the /bbo/config.txt file as shown in Appendix F.

/ to continue, ...

References

(1) The OP's NFC RFID Controller Module

(2) SunFounder Rpi PN532 NFC Module Tutorial

(3) Libnfc NFC Library

(4) Libnfc Configuration Manual

(5) Libnfc Main Page

(6) Libnfc: configuration

(7) Libnfc: nfc-list

(8) MIFARE Card

Appendices

Appendix A - Installing libnfc 1.7.1

Appendix B - Reading a tag

Appendix C - NFC Reader Tested

Appendix D - My NFC readers and tags

Appendix E - PN532 NFC reader V3 Wiring

Appendix F - SPI configuration for testing PN532 using libnfc 1.1.7

Your step 4, editing /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist worked for me and it is the only clean solution I could find.

Here a short description what you need to do:

• disable 'System Integrity Protection'
• removes 3 matching lines (with the same array index!) from the the 3 arrays ifdFriendlyName, ifdVendorID and ifdProductID of the plist /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist
• enable 'System Integrity Protection'

The three lines in my case were the entry number 370:

• ifdFriendlyName="ACS ACR122U PICC Interface"
• ifdVendorID=0x072F
• ifdProductID=0x2200

Detailed step by step description:

1. unplug your NFC card reader
2. shut down OSX
3. hold down the keys + on the keyboard while starting your Mac to enter recovery mode
4. in the recovery mode open a Terminal Window using the 'Utility' menu
5. execute the command csrutil disable
6. reboot your Mac normally

7. open a Terminal window and execute the following commands:

You seem to be mixing two different options for connecting the ACR122U to libnfc:

1. You can either use the direct USB driver for the ACR122U, libnfc.driver.acr122_usb (which is what you are currently using). In this case, you need to make sure that the PC/SC daemon does not take over control of the reader (since only one instance can access the USB interface of the reader at a time).

   • The quick-and-dirty fix is to disable the PC/SC daemon that takes control over the ACR122U. Though this is not straight forward on Mac OS X, a detailed explanation can be found in Ludovic's blog.

   • Alternatively, you could prevent the PC/SC daemon from taking control over that specific reader by editing /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist. You would need search for the entry

Have the same problem it was a problem on the circuit I believe. Taking it off and re putting it back solved the problem for me.

The ATS is perfectly fine. libnfc does not include the length byte in the value stored in nt.nti.nai.abtAts. Instead, the length of the ATS is stored in nt.nti.nai.szAtsLen. Consequently, the first byte is not the length byte but the format byte. It indicates that TA(1), TB(1), and TC(1) are present (Y(1) = 7h), and that the FSC is 64 bytes (FSCI = 5h). The remaining bytes then decode as:

• TA(1) = 77h: all three divisors supported for both directions
• TB(1) = 81h: FWT = 256 * 16 / f_c * 2^8 = 77 ms, SFGT = 256 * 16 / f_c * 2^1 = 600 us
• TC(1) = 02h: CID supported, NAD not supported
• Historical bytes: 80h

It seems to stand for General Kernel Interface, not that it is much useful as itself.

For example:

The libnfc-nci implementation uses a reliable mechanism of queues and message passing named General Kernel Interface (GKI) to easily communicate between layers and modules: Each task is isolated, owning a buffer (or inbox) where messages are queued and processed on arrival. This mechanism is used to send messages from the DH to the NFCC chip, and vice versa.

(Radio Frequency Identification: 11th International Workshop, RFIDsec 2015)

The issue here is that the C struct you're trying to map is packed, as (tersely) explained in the Structure/union alignment and byte order section of the docs:

By default, Structure and Union fields are aligned in the same way the C compiler does it. It is possible to override this behavior be specifying a _pack_ class attribute in the subclass definition. This must be set to a positive integer and specifies the maximum alignment for the fields. This is what #pragma pack(n) also does in MSVC.

That only makes sense if you already know about packing and alignment in C, but it's not that complicated.

By default, C structure elements are aligned to start on nice boundaries. For example, a 32-bit int following an 8-bit int doesn't run from bytes 1-4, it runs from bytes 4-7 (and bytes 1-3 are unused padding). So, ctypes follows the same rules.

That means that, while szUidLen runs from bytes 3-10 when it's defined as an array of 8-bit ints, it gets aligned to bytes 8-15 (or 4-11, depending on your compiler) when it's defined as a 64-bit int. You can see this by printing out nfc_iso14443a_info.szUidLen.offset.

So, the first one gets the bytes 7, 0, 0, 0, 0, 0, 0, 0, which is little-endian int64 for 7, while the second one gets the bytes 0, 0, 0, a, b, c, d, e, where abcde are the first 5 bytes of the next field, which is little-endian int64 for some huge number (unless the next field happens to be 0).

Of course you don't want to just guess that this is the problem. If you based your Structure on a struct from a C header, this can only be true if the header or the compile flags specify some non-default packing, like the #pragma pack(1) used by MSVC. If you based your Structure on something like an RFC packet description, the alignment is not even according to C rules, but is defined somewhere in the documentation you're reading (although protocol RFCs almost always use 1-byte alignment).

Anyway, the docs don't explain the problem very well, but they explain the solution: