Don't connect it to the build yet because the corresponding code in the library
has not been committed yet: I want to keep a track of modifications I do in the
VCS.
The 5th byte of Mifare DESFire being a "historical character" and being
user-tweakable for Mifare DESFire EV1, we should not use it when comparing the
ATS with our Mifare DESFire reference ATS to determine if a given tag is a
Mifare DESFire or not.
This feature was not used by the cards I initially used when coding the
, but is required for (at least some) Mifare DESFire EV1 to work.
IMPORTANT NOTE: The cards needing this block-number management to work out
break-down when mifare_desfire_format_picc() is performed on them. The ATR
change from 0x7577810280 to 0x757781028f and further communication alway result
in a timeout. At the time of committing, the reason is still unknown (bogus
cards, missed "Remarks" in the documentation, ...). Other commands seems to
not expose additional problems.
r565 was misinterpreted as a bug while it's a feature. Since it might be
inappropriate to do irreversible operations in an example, warn the user about
it.
- Lookup for crypto functions in libcrypto instead of libssl. Some systems
(Mac OS) do not provide libssl, and the other have crypto functions in
libcrypto but libssl is dynamically linked against libcrypto:
% ldd /usr/lib/libssl.so
/usr/lib/libssl.so:
libcrypto.so.6 => /lib/libcrypto.so.6 (0x800c00000)
libc.so.7 => /lib/libc.so.7 (0x800647000)
- Do not explicitly link against libssl (instead of libcrypto BTW): the
autotools magic already does this at some point;
- Improve error message when headers cannot be found.
After trying to tweak gindent so that it does not mess-up my ASCII art, give
and read the help of Vim to setup 'cinoptions' according to my needs
(cino=t0(0). This changeset reindent some bits that where not indented as they
should. A future commit will reindent the switch/case according to my (bad)
taste now that I have setup cindent correctly on my system (cino=t0(0:0).
nfc_initiator_transceive_dep_bytes() was removed, and
nfc_initiator_transceive_bytes() is now configured to behave like the one or
the other of the original functions. For details, see:
http://code.google.com/p/libnfc/source/detail?r=592
Many command return 1 byte, and my documentation does not tell what it's
supposed to be. However, this byte is always 0 when running the regression test
suite. It's likely to be an error code with value 0 being a no-error code.
Assume this and check that the returned byte is always 0.
