There is a small typo in contrib/win32/libnfc/buses/uart.c, libnfc/drivers/acr122_usb.c, libnfc/drivers/acr122s.c, libnfc/drivers/arygon.c, libnfc/drivers/pn532_uart.c, libnfc/drivers/pn53x_usb.c.
Should read `mechanism` rather than `mecanism`.
pcsc.c:763:12: warning: ‘pcsc_initiator_deselect_target’ defined but not used [-Wunused-function]
static int pcsc_initiator_deselect_target(struct nfc_device *pnd)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Modify pcsc.c and mifare.c files.
1. add code into pcsc.c to have support Mifare classic card.
2. The PCSC reader has SW value, add response data length for PCSC
reader
If the user specifically requests the driver, throw an error if it
cannot find libnfc-nci.
Also use the value from pkg-config to determine the library name,
instead of hard-coding it.
1. Modify pcsc.c code, add R502 and bR500 support into PCSC driver
2. Update readme, tell user how to build with pcsc driver
3. Add FAQ for bR500 and R502 in readme
Adding pn71xx NXP's NFC Controllers through Linux Libnfc-nci
(note I have only tested this does not break build etc. as I do not have a reader with this chipset)
- only initiator mode is supported
- properties are choosen as they are available via PC/SC, the rest of
the defaults are chosen to be compatible with Mifare DESFire
- This commit allows reading Mifare DESFire via PC/SC with libfreefare
stdint.h is needed for uintX_t typedefs which are
used to replace u_intX_t in libusb API headers in the cmake files
Signed-off-by: Khem Raj <raj.khem@gmail.com>
PN533 easily corrupts its USB descriptors. We know that and we
already try to detect and even repair them.
However there are situations where lower software layers get
confused before libnfc can help. On Windows, libusb may set
dev->config to NULL, but we can also have a non NULL dev->config
referencing corrupted data.
In order to get more robust, let us replace the Windows libusb
specific (dev->config == NULL) test by an inconditionnal use of
hardcoded descriptors when they are available.
The problem occurs in the following succession of events:
* Emit commands returning an answer larger than 16 bytes
* Re-enumerate USB devices without power cycle, e.g. a warm reboot of the PC
The bug can be reproduced for testing purposes with usbreset.c from
https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line#661
$ lsusb|grep NFC
Bus 001 Device 010: ID 04e6:5591 SCM Microsystems, Inc. SCL3711-NFC&RW
$ sudo ./usbreset /dev/bus/usb/001/010
Resetting USB device /dev/bus/usb/001/010
Reset successful
$ echo -e "4a 01 00\n423000" |pn53x-tamashell
$ sudo ./usbreset /dev/bus/usb/001/010
Resetting USB device /dev/bus/usb/001/010
Error in ioctl: No such device
$ lsusb|grep NFC
... device disappeared
In the example above, reading 4 pages of a MFUL corrupted one single byte.
The entire buffer can be corrupted e.g. with fast-reading a MFUL EV1:
$ echo -e "4a 01 00\n423a0013"|pn53x-tamashell
The problem occurs in the following succession of events:
* Emit commands larger than 17 bytes
* Re-enumerate USB devices without power cycle, e.g. a warm reboot of the PC
The bug can be reproduced for testing purposes with usbreset.c from
https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line#661
$ lsusb|grep NFC
Bus 001 Device 010: ID 04e6:5591 SCM Microsystems, Inc. SCL3711-NFC&RW
$ sudo ./usbreset /dev/bus/usb/001/010
Resetting USB device /dev/bus/usb/001/010
Reset successful
$ echo 06000000000000000000000000000000000000 |pn53x-tamashell
$ sudo ./usbreset /dev/bus/usb/001/010
Resetting USB device /dev/bus/usb/001/010
Error in ioctl: No such device
$ lsusb|grep NFC
... device disappeared
After a DESfire operation SCL3711 will sometimes enter a state where
libusb-0.x is unable to fill config field in struct usb_device. The
USB device has to be power-cycled to restore a sane state.
This introduce a work around, by using hardcoded values for endpoints
and packet size when they are unavailable.
