When you have more than one NFC device connected to the same computer, it's
a little confused to know which one you are using.
Due to readers auto-detection, we can't control which device you are using.
Things goes harder with program that need two devices like nfc-emulate or
nfc-relay.

Man page is missing for mfultool.

I added NFCIP support to libnfc. It is a messy patch, but it works (see
included initiator and target example apps). You need two readers to test
this. The initiator and target send each other a simple "Hello World/Mars"
message.

Issues with the patch:
- I copied some functions and added "dep" in their name when the PN53x
instruction is different, this could be optimized a bit by having some kind
of configuration somewhere to indicate that DEP / NFCIP is used
- NFCIP needs to activate the target, which is something else than
selecting it apparently (different command)

The patch is against latest svn (r71).

There is no getopt in Windows afaik, so some of the tools are not going to
work there. Tried with Visual C++ 2008 Express.

Maintaining two files with almost 90% of same code is asking for bugs.
We can change the driver to PN53XUSB (direct USB support for 1 and 3 version)

Reported by ud at http://www.libnfc.org/community/post/487/#p487

What steps will reproduce the problem?
1. Build libnfc trunk sources:

./configure --disable-pcsc-lite --disable-libusb
make
sudo make install

2. Run "nfc-list" or "nfc-anticol" tools.

What version of the product are you using? On what operating system?
Linux Ubuntu 9.10 - libnfc 1.3.0 r228.

The result is:

1. nfc-list:

nfc-list use libnfc 1.3.0 (r227)
INFO: No device found.

2. nfc-anticol:

Segmentation fault

messages.h is not included in dev_pn531.c thus the use of DBG macro on line 125 
causes 
compilation to fail.

At r138, nfc-mftool have a nice feature: it could try to read a MIFARE card
using "defaults" keys.
But the output is not clear:

nfc-mftool r a dump.mfd

Checking arguments and settings
Succesful opened MIFARE the required files
Connected to NFC reader: ACR122U102 - PN532 v1.4 (0x07)
Found MIFARE Classic 1K card with uid: ec81d51a
Reading out 64 blocks |............xxxx|
Writing data to file: dump.mfd
Done, all bytes dumped to file!

What does mean dots '...' and crosses 'xxx" ? If crosses are failures, we
shouldn't have a "Done, all bytes dumped to file!" message.

The library is not correctly linked in a C++ environment.

Reference:
http://www.dwheeler.com/program-library/Program-Library-HOWTO/x214.html

The solution is:

1) Define a macro in "defines.h" like this:

// Linkage specification macro
#if defined __cplusplus 
    #define NFCAPI extern "C" 
#else
    #define NFCAPI
#endif

2) Add "NFCAPI" prefix before each API method signature:

/* libnfc.h */
NFCAPI dev_info* nfc_connect();

/* libnfc.c */
NFCAPI dev_info* nfc_connect()
{
    // ...
}

The path to the library and include files is wrong in libnfc.pc.in. See
attached patch for a fix.

I created a NDEF parser example tool (nfc-ndef) that at this time can parse
a MFUL tag (among others the one from Tikitag/Touchatag) to extract the
NDEF URL stored in it. 

The code is universal in that it is easy to implement support for other
NDEF tags / message types as well, but it seems this one is best suited as
an example as most people will have the Tikitag tags lying around. In the
future a complete NDEF parser may be a possibility separate from this
project (as part of nfc-tools project?) 

Extending it to MIFARE Classic support (1k/4k) is trivial.

I didn't want to commit it just yet as the source style / copyright etc.
may not be what is required for this project :-) I used "indent -kr -i4" to
format the source. It's been a while since I was fluent in C :-)

The copyright owner can be changed if needed, as long as it remains GPLv3+ :)

During compilation of libnfc using Solaris SUNWspro compiler.

The struct dev_callbacks_list is initialised with addresses of functions 
in "devices.h". This is incompatible with the struct being "packed".

Move the pack pragma in "types.h" to around only those types that truely 
need to be packed.

I actually own a APDB2UA33 OEM module. For my first try, I had used a 
USB-UART converter to connect the OEM module on a PC.
I had compiled libnfc 1.2.1 using --enable-debug flag (under GNU/Linux) 
and had executed nfc-list:
{{{
Trying to find ARYGON device on serial port: /dev/ttyUSB#
Succesfully connected to: /dev/ttyUSB0
Tx: 32  00  00  ff  04  fc  d4  06  00  00  26  00
Tx: 32  00  00  ff  02  fe  d4  02  2a  00
Error connecting NFC reader
}}}

The files libnfc.h and bitutils.h need the following in the header.

#ifdef _WIN32
#  ifdef nfc_EXPORTS
#    define NFC_LIB_EXPORT  __declspec( dllexport )
#  else
#    define NFC_LIB_EXPORT  __declspec( dllimport )
#  endif
#else
#  define NFC_LIB_EXPORT 
#endif

Furthermore, for every function that needs to be exported (i.e.: callable
from the outside world) should have "NFC_LIB_EXPORT" prepended.

Example:
NFC_LIB_EXPORT dev_info* nfc_connect(void);

In bitutils.h the functions "print_hex*" and "swap_endianess*" also need to
be "exported" because some tools use them.

These header modifications will be used by CMake to generate a DLL + LIB
file for libnfc.

In the current version, there is not a complete support for the last
revision of NXP PN532 chip (C106).

It has two important features:

- It starts in "sleep mode" and needs a specific command to wake-up.
- It only works in handshake mode.

Reference: http://www.libnfc.org/community/topic/57/add-support-for-pn532-chip/

With 1.2.0 version, some serial devices (ARYGON) are now supported. 
During nfc-list (for example), libnfc will probe serial port and this can 
be annoying if there are others devices plugged on serial port.

The code currently contains:

if (!bPar) nfc_configure((dev_info*)pdi,DCO_HANDLE_CRC,true);

which sets the CRC property based on the bPar flag.  There's a section
further on that sets it back similarly.  This should probably set the
PARITY property instead.

I haven't created a test case from this, but it appeared pretty clear what
the code was intended to do, and what it actually does.  I've attached a
patch that should correct the issue.  This still applies to revision 163.

If you need any further information, do just ask.  Thanks...  5:)

there seems to be a problem with delay_ms(), is this linux internal?

>nfc-list 
dyld: lazy symbol binding failed: Symbol not found: _delay_ms
  Referenced from: /usr/local/lib/libnfc.0.dylib
  Expected in: dynamic lookup

dyld: Symbol not found: _delay_ms
  Referenced from: /usr/local/lib/libnfc.0.dylib
  Expected in: dynamic lookup

Trace/BPT trap

Instead of using a wiki page to document API, it should be more easy for 
developers to write theses comment within source code. Using Doxygen, we 
will be able to produce an online documentation (html), an offline 
documentation (pdf) and have commented code.

There are two issues when packaging for Fedora:

1. The std=c99 CFLAGS should not be used on Fedora (Fedora 11, GCC 4.4),
with it the software won't compile, without it everything works fine (I
created a patch to fix this for Fedora). I'm not sure it compiles on
Debian/other systems without this CFLAGS?

2. The use of rpath. This is deprecated, also on Debian, but by default
rpath is included. I "fixed" this by re-running libtoolize on Fedora which
takes care of this, it does not seem to be possible to just modify the
libtool script ./configure generates.


Is it possible to remove the "std=c99" or will this be a problem for other
platforms? 

It it possible to "fix" libtool to not include rpath by default? Or have
some configure parameter for ./configure which takes care of this? (e.g.:
--disable-rpath)

The Fedora package (srpm and spec file) can be found at
http://fkooman.fedorapeople.org/libnfc/

We should remove [dirty] global variables if we want to be 
more "thread-safe".

http://www.libnfc.org/community/topic/45/code-review-of-libnfc/

(Thanks to snapdev)

With renaming those, we get a better overview in the /src directory what is
used for example tool and what are the actual (core)source files.

Current svn trunk (r99) can now handle a NFC connection to a specified
device. For ARYGON readers (and PN532 using UART) serial port can be
specified but not serial speed.
Actually speed is hardcoded (in rs232.c) and can become a problem if a
serial NFC reader doesn't use 115200 bauds.

dev_pn531.c(176)
  char abtTx[BUFFER_LENGTH] = { 0x00, 0x00, 0xff }; // Every packet must 
start with "00 00 ff"

Need to prefix the 0xff with (char) or use an array of "byte_t" instead of 
char.

We may want to consider nfc_initiator_select_tag() to be renamed to
nfc_initiator_select_target(). Where we use the "pbtInitData" parameter for 
(structs & unions) that corresponds to the active "init_modulation" type.

For DEP transactions this could hold pbtPidData/pbtNFCID3i/pbtGbData (using
structs & unions). This may improve the understanding of "pbtInitData" for
developers, since they are guided by a struct to supply additional info.

Furthermore this will bring down the total amount of "similar-code", plus
it will keep the API tight and clean.

Last but not least, we could save the current used "init_modulation", to
cut down the extra "tranceive()" functionality, since this only differs in
the command for the PN53X chipset.

- fix CMake pkg-config generation because the list of "Requires:" is dynamic
- fix devices.h, #endif should not be followed by the name of the block
- fix CMake libnfc_usb compilation, dev_pn531 and dev_pn533 are two files
- rename tools to examples in CMake file

What steps will reproduce the problem?
1. compilation with Microsoft Visual C++ 6.0
2.
3.

Preprocessor fails on defines in messages.h (DBG, INFO, WARN, ERR) as 
defines require variable arguments. This is not portable.

Source repository contains win32 subdirectory with some compiled objects.

Thanks to Fkooman, libnfc have now CMake files. That allow us to provide an
automatically generated archive like "make dist" with autotools but also
for Windows.
As suggested by Fkooman, CMake can produce an installable binary too: "That
should be no problem now with this CMake/MSVC/NSIS stuff."

It would be nice to have an "auto-authentication" option in "mftool".

Usage example:

mftool r a dump.mfd
(this is the new usage form)

mftool r a dump.mfd keys.mfd
(please, note the switch between dump and keys for the old usage form)

If no "keys" dump file is specified, the tool tries to authenticate with a
standard key list:

byte_t keys[] = {
    0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,
    0xd3,0xf7,0xd3,0xf7,0xd3,0xf7,
    0xa0,0xa1,0xa2,0xa3,0xa4,0xa5,
    0xb0,0xb1,0xb2,0xb3,0xb4,0xb5,
    0x4d,0x3a,0x99,0xc3,0x51,0xdd,
    0x1a,0x98,0x2c,0x7e,0x45,0x9a,
    0xaa,0xbb,0xcc,0xdd,0xee,0xff
};

Pseudo code:

// Set the authentication information (uid)
memcpy(mp.mpa.abtUid,ti.tia.abtUid,4);

// Determin if we should use the a or the b key
mc = (bUseKeyA) ? MC_AUTH_A : MC_AUTH_B;

int num_keys = sizeof(keys) / 6;

for (int i = 0; i < num_keys; i++)
{
    memcpy(mp.mpa.abtKey, keys + (i*6), 6);
    if (nfc_initiator_mifare_cmd(device, mc, block, &mp))
        return true;

    nfc_initiator_select_tag(device, IM_ISO14443A_106, mp.mpa.abtUid, 4, NULL);
}

return false;

There are Doxygen comments in libnfc but actually, libnfc build systems
doesn't compile this documentation.

When libnfc is used with ACR122 device, a tag need to be present to be 
able to see the reader.
If you try to use this reader with nfc-list without tag you will 
see "Error connecting NFC reader" exactly the same message when you 
haven't any readers connected.

Actually, we have one tool to manipulate MIFARE Classic, and another one
for MIFARE Ultralight, it should be cleaner if we merge them.

When making the migration to 64 bit environments we may want to take care
of making the parameter typing to be more abstract. size_t sounds as more
than a useful successor for this task ;)

Reported by ud at http://www.libnfc.org/community/post/488/#p488

We need to fill Windows section in
http://www.libnfc.org/documentation/installation

Any volunteer ?

src/initiator.c, src/target.c and win32/stdint/stdbool.h do not have 
Copyright banners.

I've created a few CMake build system files for libnfc as an experiment.
There are still some issues on Windows, and windows support is not part of
the current CMake scripts, but on Linux it seems to work great (tested with
Fedora 11 and Ubuntu 9.04).

On Windows I get a bit confused about the winscard.DLL/winscard.LIB files
etc and how to generate a LIB file from a DLL file. CMake can automatically
generate Visual Studio project files for any version, so that would be a
nice benefit! 

Although when using the winscard.LIB file that is now part of the SVN repo
it all seems to work, but it is not really nice to have a blob in the
source repo.

I attach two files, CMakeList.txt which should be placed in the project
root and CMakeListSRC.txt which should be placed in the "src" directory and
also have the name CMakeList.txt. To compile the whole stuff (out of src
tree) create for example a directory "bin" in the project root:

$ cd /path/to/libnfc-1.2.2/
$ mkdir bin
$ cd bin
$ cmake ..
$ make
$ sudo make install  (installs in /usr/local/*)

Maybe at some point (when the Windows issues are resolved) it can be
considered a replacement for Autotools.

- make disable serial probe configurable in GUI, default to off
- add sources of getopt tools to all builds except windows

What steps will reproduce the problem?

1. Compilation on PowerPC MacOSX 10.4.11, gcc -Wall -Werror

What is the expected output? What do you see instead?

../../libnfc/src/libnfc.c:876: warning: passing argument 5 
of 'pn53x_transceive' from incompatible pointer type

In function  nfc_target_receive_bytes szRxLen was uint32_t

should be size_t szRxLen=sizeof(abtRx);

Currently, the PN532 UART driver seems to be very slow compared with a
Nokia NFC phone (read and write actions on Mifare tags).

The main cause seems to be the 50ms delay added to the "transceive"
function for stability needs. So, I've tried to remove it and...surprise!
It works! :)

With the delay I need 18~20s to read/write a Mifare Classic 1K tag. Without
it the tag is written/read in ~10s. It's still slower than the Nokia phone
(which reads a vCard from a Mifare 1K in only 1~2s), but surely more
acceptable.

Probably the magic is done by recent changes to UART read/write functions
(r183, r184).

So, in my opinion, we can remove it if the situation is confirmed by more
accurate tests and benchmarks.

Since r105, PN532 UART based NFC devices can be used with libnfc without
any stability issue... But we have to use a delay in dev_arygon.c (around
50ms to be stable).
This delay is needed to receive a full TAMA frame for PN532.
Unfortunately, if we use a slower transmission like 9600 baud, this delay
have to be extended or it appends this:

 TX: 32  00  00  ff  04  fc  d4  4a  01  00  e1  00
 RX: 00  00  ff  00  ff  00
 TX: 32  00  00  ff  04  fc  d4  4a  01  00  e1  00
 RX: 00  00  ff  0f  f1  d5  4b  01  01  00  44  00  07  04  a3  12  61  ee
 02  80  09  00  00  00  ff  00  ff  00
 TX: 32  00  00  ff  04  fc  d4  4a  01  00  e1  00
 RX: 00  00  ff  0f  f1  d5  4b  01  01  00  44  00  07  04  a3  12  61  ee
 02  80  09  00  00  00  ff  00  ff  00  00  00  ff  0f  f1
 TX: 32  00  00  ff  04  fc  d4  4a  01  00  e1  00
 RX: d5  4b  01  01  00  44  00  07  04  a3  12  61  ee  02  80  09  00  00
 00  ff  00  ff  00
 TX: 32  00  00  ff  04  fc  d4  4a  01  00  e1  00
 RX: 00  00  ff  0f  f1  d5  4b  01  01  00  44  00  07  04  a3  12  61  ee
 02  80  09  00  00  00  ff  00  ff  00  00

If you take care: RX start doesn't and TAMA start does match each time.

The cleanest way, IMHO, is to retrieve TAMA frame from RS232/UART using a
circular buffer which is able to keep all received bytes in a buffer and
export only full TAMA frame.
Using this way, we will be able to check TAMA frame struct (length and
checksum).

If crosses are failures, we
shouldn't have a "Done, all bytes dumped to file!" message.

See:

http://code.google.com/p/libnfc/issues/detail?id=38

Mac OS X installation instruction available at
http://www.libnfc.org/documentation/installation are outdated.

I think there is an error in mftool code at line 107:

if (!nfc_initiator_mifare_cmd(pdi,MC_AUTH_A,iBlock,&mp))

should be:

if (!nfc_initiator_mifare_cmd(pdi,mc,iBlock,&mp))

It should be helpful to have a little function to get library version at
runtime.
This can be done using config.h generated by Autotools under POSIX.

With the current rs232 receive function, I experimented some buffer
synchronization problems during the pn532C106 support implementation
process (see: http://code.google.com/p/libnfc/issues/detail?id=15).

With my patch (Linux only), the function reads exactly the number of bytes
currently in the buffer:



bool rs232_receive(const serial_port sp, byte_t* pbtRx, uint32_t* puiRxLen)
{
  int iResult;
  int byteCount;
  fd_set rfds;

  // Reset file descriptor
  FD_ZERO(&rfds);
  FD_SET(((serial_port_unix*)sp)->fd,&rfds);
  iResult = select(((serial_port_unix*)sp)->fd+1, &rfds, NULL, NULL, &tv);

  // Read error
  if (iResult < 0) return false;

  // Number of bytes in the input buffer
  ioctl(((serial_port_unix*)sp)->fd, FIONREAD, &byteCount);

  // Read time-out or empty buffer
  if (iResult == 0 || byteCount == 0) return false;

  // There is something available, read the data
  *puiRxLen = read(((serial_port_unix*)sp)->fd,pbtRx,byteCount);

  return (*puiRxLen > 0);
}

What steps will reproduce the problem?
1. compilation with Microsoft Visual C++ 6.0
2.
3.

What is the expected output? What do you see instead?

swap_endian64()

bitutils.c(120) : error C2059: syntax error : 'bad suffix on number'
bitutils.c(120) : error C2146: syntax error : missing ')' before 
identifier 'l'
bitutils.c(120) : error C2059: syntax error : 'bad suffix on number'
bitutils.c(120) : error C2059: syntax error : 'bad suffix on number'
bitutils.c(120) : error C2059: syntax error : 'bad suffix on number'

What version of the product are you using? On what operating system?

Windows XP

Please provide any additional information below.

I got around this by commeting out the whole function. I did not need it 
for pn531.

The README file has DOS line endings, this is inconsistent with the rest of
the text files in the distribution.

Fix:
sed -i 's/\r$//' README