nfc-tools / libnfc Goto Github PK
View Code? Open in Web Editor NEWPlatform independent Near Field Communication (NFC) library
Home Page: http://nfc-tools.org
License: GNU Lesser General Public License v3.0
Platform independent Near Field Communication (NFC) library
Home Page: http://nfc-tools.org
License: GNU Lesser General Public License v3.0
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
Original issue reported on code.google.com by emanuele.bertoldi
on 2 Dec 2009 at 11:43
- make disable serial probe configurable in GUI, default to off
- add sources of getopt tools to all builds except windows
Original issue reported on code.google.com by fkooman%[email protected]
on 4 Sep 2009 at 9:18
Attachments:
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+ :)
Original issue reported on code.google.com by fkooman%[email protected]
on 19 Oct 2009 at 4:06
Attachments:
src/initiator.c, src/target.c and win32/stdint/stdbool.h do not have
Copyright banners.
Original issue reported on code.google.com by [email protected]
on 7 Oct 2009 at 12:51
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.
Original issue reported on code.google.com by fkooman%[email protected]
on 2 Sep 2009 at 10:18
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).
Original issue reported on code.google.com by [email protected]
on 14 Sep 2009 at 4:40
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.
Original issue reported on code.google.com by [email protected]
on 23 Jul 2009 at 1:58
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).
Original issue reported on code.google.com by fkooman%[email protected]
on 22 Aug 2009 at 4:31
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 26 Aug 2009 at 10:26
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
}}}
Original issue reported on code.google.com by [email protected]
on 3 Aug 2009 at 8:42
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
Original issue reported on code.google.com by emanuele.bertoldi
on 19 Nov 2009 at 10:53
Source repository contains win32 subdirectory with some compiled objects.
Original issue reported on code.google.com by [email protected]
on 8 Sep 2009 at 8:00
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:)
Original issue reported on code.google.com by [email protected]
on 2 Nov 2009 at 4:49
Attachments:
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()
{
// ...
}
Original issue reported on code.google.com by emanuele.bertoldi
on 3 Sep 2009 at 1:39
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);
}
Original issue reported on code.google.com by emanuele.bertoldi
on 4 Sep 2009 at 10:25
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.
Original issue reported on code.google.com by [email protected]
on 30 Sep 2009 at 9:58
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)
Original issue reported on code.google.com by [email protected]
on 25 Sep 2009 at 11:18
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.
Original issue reported on code.google.com by emanuele.bertoldi
on 8 Dec 2009 at 3:53
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.
Original issue reported on code.google.com by [email protected]
on 4 Oct 2009 at 10:39
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.
Original issue reported on code.google.com by [email protected]
on 5 Oct 2009 at 12:47
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/
Original issue reported on code.google.com by fkooman%[email protected]
on 21 Aug 2009 at 6:31
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
Original issue reported on code.google.com by fkooman%[email protected]
on 21 Aug 2009 at 4:09
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.
Original issue reported on code.google.com by [email protected]
on 5 Oct 2009 at 3:29
messages.h is not included in dev_pn531.c thus the use of DBG macro on line 125
causes
compilation to fail.
Original issue reported on code.google.com by [email protected]
on 26 Sep 2009 at 1:26
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
Original issue reported on code.google.com by [email protected]
on 31 Oct 2009 at 2:08
Man page is missing for mfultool.
Original issue reported on code.google.com by [email protected]
on 21 Sep 2009 at 3:09
There is no getopt in Windows afaik, so some of the tools are not going to
work there. Tried with Visual C++ 2008 Express.
Original issue reported on code.google.com by fkooman%[email protected]
on 31 Aug 2009 at 9:28
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);
Original issue reported on code.google.com by [email protected]
on 5 Oct 2009 at 1:46
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.
Original issue reported on code.google.com by [email protected]
on 3 Aug 2009 at 3:29
The path to the library and include files is wrong in libnfc.pc.in. See
attached patch for a fix.
Original issue reported on code.google.com by fkooman%[email protected]
on 15 Aug 2009 at 6:44
Attachments:
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/
Original issue reported on code.google.com by emanuele.bertoldi
on 3 Sep 2009 at 1:18
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 ;)
Original issue reported on code.google.com by [email protected]
on 30 Sep 2009 at 10:13
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;
Original issue reported on code.google.com by emanuele.bertoldi
on 28 Sep 2009 at 1:57
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.
Original issue reported on code.google.com by [email protected]
on 3 Aug 2009 at 8:53
Reported by ud at http://www.libnfc.org/community/post/488/#p488
Original issue reported on code.google.com by [email protected]
on 9 Nov 2009 at 9:38
Reported by ud at http://www.libnfc.org/community/post/487/#p487
Original issue reported on code.google.com by [email protected]
on 9 Nov 2009 at 9:32
- 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
Original issue reported on code.google.com by fkooman%[email protected]
on 12 Sep 2009 at 6:59
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 4 Oct 2009 at 10:37
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))
Original issue reported on code.google.com by emanuele.bertoldi
on 18 Sep 2009 at 3:07
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.
Original issue reported on code.google.com by [email protected]
on 6 Oct 2009 at 4:44
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.
Original issue reported on code.google.com by [email protected]
on 4 Oct 2009 at 10:35
We need to fill Windows section in
http://www.libnfc.org/documentation/installation
Any volunteer ?
Original issue reported on code.google.com by [email protected]
on 26 Oct 2009 at 9:30
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.
Original issue reported on code.google.com by [email protected]
on 8 Sep 2009 at 8:05
Actually, we have one tool to manipulate MIFARE Classic, and another one
for MIFARE Ultralight, it should be cleaner if we merge them.
Original issue reported on code.google.com by [email protected]
on 24 Jul 2009 at 4:43
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.
Original issue reported on code.google.com by [email protected]
on 29 Sep 2009 at 8:11
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.
Original issue reported on code.google.com by fkooman%[email protected]
on 31 Aug 2009 at 9:37
Attachments:
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)
Original issue reported on code.google.com by [email protected]
on 23 Jul 2009 at 1:42
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."
Original issue reported on code.google.com by [email protected]
on 8 Sep 2009 at 8:28
Mac OS X installation instruction available at
http://www.libnfc.org/documentation/installation are outdated.
Original issue reported on code.google.com by [email protected]
on 26 Oct 2009 at 9:29
There are Doxygen comments in libnfc but actually, libnfc build systems
doesn't compile this documentation.
Original issue reported on code.google.com by [email protected]
on 24 Sep 2009 at 1:31
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.