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
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.
The datasheet is wrong for the pn532_i2c. After having constant issues
with the device failing to respond on the bus and after contacting NXP
about this, it turns out 1.3 ms is too tight. The official timing spec
is unknown for now, but we tested 4 and 5 ms without problems. Thus we
have choosen 5 ms as a safe delay.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Currently, we very occasionally can EXNIO errors from pn532_i2c_write() ->
i2c_write() -> write(). This may happen about once every 30 seconds.
Based from the kernel sources, EXNIO happens if the chip no longer
responds to its own address.
To make sure we do not loose any sent packets, we retry to send
PN532_SEND_RETRIES number of times. Since we miss 1 every 30 or so
seconds, doing 1 retry should be fine.
This might be considered a hack as the failure may be some other timing
related issue.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
The pn532 user manual states that after a i2c stop condition and before a i2c
start condition there should be a delay of minimally 1.3 milliseconds.
This is probably a limitation of the i2c peripheral or the firmware. In
any case, each i2c_read and i2c_write creates the packets which are
complemented with start/stop markers. It is thus required to take care
of timing in these two functions.
We solve this by wrapping the lower i2c_read and i2c_write functions for
the pn532, as this requirement is not for all chips.
Currently, we keep time using local variable, and thus the code is not
thread-safe. With libnfc being single threaded and only one instances of
libnfc can open a bus anyway, this is not yet a problem.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
The pn532 documentation differs slightly from the included ascii art
documentation on how a packet looks like. The preamble was omitted
however the postamble is mentioned. This patch adds the Preamble to the
ascii frame documentation.
The code later refers incorrectly to the start byte as the preamble.
This variable was renamed to more descriptively state that it is the
preambe and the start bytes.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
pn532_uart.c:293:5: warning: Use of memory after it is freed
log_put(LOG_GROUP, LOG_CATEGORY, NFC_LOG_PRIORITY_ERROR, "pn53x_check_communication error on %s", ndd.port);
^ ~~~~~~~~
Calling ioctl flush too fast before actual garbage bytes arrive was useless.
It solves an issue e.g. when config asks for scanning for multiple incompatible serial devices:
One scan can mess up the reader and we've to wait & flush properly for the next driver to be able to scan correctly
Redundant result check leading to dead code was probably indicative
of a missing return value check of acr122_usb_send_apdu()
Problem reported by Coverity:
at_least: At condition "res < 0", the value of "res" must be at least 12.
cannot_single: At condition "res < 0", the value of "res" cannot be equal to -6.
dead_error_condition: The condition "res < 0" cannot be true.
CID 1090327 (#1 of 1): Logically dead code (DEADCODE)
dead_error_begin: Execution cannot reach this statement "acr122_usb_ack(pnd);".
Problem reported by Coverity:
CID 1090322 (#1 of 1): Unchecked return value (CHECKED_RETURN)
unchecked_value: No check of the return value of "pn53x_build_frame(abtFrame, &szFrame, pbtData, szData)".
