I successfully compiled libnfc1.5.1 using ubuntu 11.10 with package libusb-dev and an SCL3711 USB reader. But, when testing with utils/nfc-list, I get a message "no device found".

dmesg only says "usb 6-1: new full speed USB device number 5 using uhci_hcd".

Is there anything to do in order to get libusb working with the SCL3711?

Thank you!

As there are many users who ask about ACR122, I would like to clarify why this is a bad idea to use ACR122 (and derivated like Touchatag), at least with libnfc.

First, I have to say these devices are well-packaged, are cheap, have a nice look and work perfectly as RFID @13.56Mhz reader using PC/SC on common platforms as these devices are CCID compliant.

Internally, an ACR122 device is made with an MCU, a NFC chip (PN532) and an antenna.
MCU made the device CCID compliant and provide an USB connection.

Now let's talk about NFC and underlying requierements: to do more than RFID reader, you will need to:
- Poll for different targets (NFC-A, NFC-B, NFC-F and DEP)
- Act as target in ISO/IEC 14443-4 emulation mode (optionnal regarding NFC Forum but very useful to be backward compatible with device that are not able to do P2P)
- Do P2P as defined in "Logical Link Control Protocal" (LLCP) from NFC-Forum

Polling and acting as target need to be cancellable, ie. you start a target emulation but no initiator comes, you will have to abort the target emulation.
Next, LLCP defines some timeouts for command sending/receiving but long timeouts relies on "abortable" commands.

In actual architecture, libnfc directly talk to NFC Chip (PN532).
To do that, libnfc's ACR122 driver passthrough PC/SC (and internal MCU) by using some special commands that allow to send frames directly to the PN532.
So with ACR122, the libnfc relies on PC/SC but there is no timeout on command and no way to cancel a running command in PC/SC API.

Conclusion, we can't do reliable and robust NFC with ACR122 and libnfc.

Of course, any contributions are more than welcome to fully support ACR122 devices in libnfc.

I started experimenting around with my touchatag and some mifare cards. As I still
have some old cards from which are not in use anymore I wanted to clear or format them
to put my own data on them.

Sadly, they have no default keys but I managed to get around this problem and got
them with mfoc. I put them into the default_keys[] array in the mifare-classic-format.c
but it still complains about having no valid key:

"No known authentication key for sector 0"

I double-checked the keys I got from mfoc with the ones I put into the source but still
no success.

Is there some way to just check if the key I used was correct?

Or maybe another way to "clear" a mifare-card to default values?

Greetings,
Gesar

maybe someone can give me a hint what I am missing but I have a problem getting libnfc build in a package. I am running a Ubuntu 10.04 system and I follow the steps described at this link: http://www.libnfc.org/documentation/installation
I would like to create a package, so here are the steps I performed:

wget hxxp://libnfc.googlecode.com/files/libnfc-1.5.1.tar.gz
tar -xvzf libnfc-1.5.1.tar.gz
cd libnfc-1.5.1/
svn checkout hxxp://libnfc.googlecode.com/svn/tags/libnfc-1.5.1/debian
dpkg-buildpackage -b -us -uc

I some point of the last step, I get the following error:

   ...
   dh_strip
   dh_makeshlibs
   dh_shlibdeps
dpkg-shlibdeps: error: no dependency information found for /usr/local/lib/libpcsclite.so.1 (used by debian/libnfc2/usr/lib/libnfc.so.2.0.0).
dh_shlibdeps: dpkg-shlibdeps -Tdebian/libnfc2.substvars debian/libnfc2/usr/lib/libnfc.so.2.0.0 returned exit code 2
make: *** [binary] Error 9
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

I tried to fix that with a file "shlibs.local" but I am not quite sure where to put it neither what the content should be. So far I tried to put it in the folder "libnfc-1.5.1/debian" as well as in "libnfc-1.5.1/"
As content I tried

libpcsclite 2 libnfc

and

libpcsclite 2 libnfc.so.2.0.0

unfortunatelly without success ...

When I am doing pcscd -v I get the following:

pcsc-lite version 1.8.2.
Copyright (C) 1999-2002 by David Corcoran <corcoran@linuxnet.com>.
Copyright (C) 2001-2011 by Ludovic Rousseau <ludovic.rousseau@free.fr>.
Copyright (C) 2003-2004 by Damien Sauveron <sauveron@labri.fr>.
Report bugs to <muscle@lists.musclecard.com>.
Enabled features: Linux i686-pc-linux-gnu serial usb libudev usbdropdir=/usr/local/lib/pcsc/drivers ipcdir=/var/run/pcscd configdir=/usr/local/etc/reader.conf.d

So I assume libpcsclite is installed, and libusb-config --version gives me 0.1.12, what also should be fine.

sudo apt-get install libusb-dev libpcsclite-dev
sudo apt-get install libusb-0.1-4 libpcsclite1 libccid pcscd

tells me everything is already the newest version ...

Does anyone has an idea?
cheers

Thanks

Regarding to card emulation, I have the following questions

a. For mifare card emulation, is there necessary a secure element, say a "mifare card" inside the device? Can we just simulate the transaction of mifare commands through APDU. For example:

ACR122U-> APDU command (read value block 0x5: FF B1 00 05 00)->ISO 14443 frame (encapsulate the APDU) -> device -> software on device handled the APDU, and return the simulated result
b. Currenty, I can let my blackberry enter into card emulation ISO144434-A, and recognized as "mifare 1k" (modified the history byte to be as same as a real mifare card). Based on my assumption, when I send command, which is not a real APDU (0x11, 0x12, 0x13, 0x14),   the software inside the phone "can" recevice my command and processs it. Also, the reader can get the dummy response
c. But if I send a real mifare APDU command (FF B1 00 05 00), the card reader always return 0x63 0x00, and my software inside the phone never receivced the command sequence from the reader.

ACR122U-> APDU command (read value block 0x5: FF B1 00 05 00)->ISO 14443 frame (encapsulate the APDU) -> device  ---X--> software on device handled the APDU, and return the simulated result

Is there anything wrong with my concept ? or there must be a really mifare card inside the device, and let NFC controller route the real mifare APDU command to the secure element. Due to blackberry didn't provide a sign key for NFC secure element APIs. I just can let the phone simulate as a pure ISO14443-A type device.

I resoldered SEL1 to GND to force PN532 into UART mode. Then I connected J8 (POWER) and J4 (PC1) to CP2102-based USB-to-UART converter like this:

GND -> J8-2 (GND)
GND -> J8-3 (GND)
+5V -> J8-4 (+5V)
RXD -> J4-5 (MOSI/SDA_)
TXD -> J4-6 (SCL/RX/SS_)

No luck. That's what nfc-list says in debug mode:

lt-nfc-list: DBG pn532_uart.c:97
lt-nfc-list:     Trying to find PN532 device on serial port: /dev/ttyUSB0 at 115200 bauds.
lt-nfc-list: DBG uart_posix.c:106
lt-nfc-list:     Serial port speed requested to be set to 115200 bauds (86 µs).
TX: 55  55  00  00  00  00  00  00  00  00  00  00  00  00  00  00  ff  03  fd  d4  14  01  17  00  
lt-nfc-list: DBG uart_posix.c:219
lt-nfc-list:     iExpectedByteCount == 6
lt-nfc-list: ERROR: No ACK.
lt-nfc-list: DBG uart_posix.c:219
lt-nfc-list:     iExpectedByteCount == 9
lt-nfc-list: ERROR: Unable to wakeup the PN532.
TX: 00  00  ff  09  f7  d4  00  00  6c  69  62  6e  66  63  be  00  
lt-nfc-list: DBG uart_posix.c:219
lt-nfc-list:     iExpectedByteCount == 22
lt-nfc-list: ERROR: Unable to receive data. (RX)

Tried 1.4.x and 1.5.x. Did I miss something?

When trying to run mfoc -O [card_dump] it gives me the following error:
nfc_initiator_select_passive_target: Success
nfc-list tells me my reader (ACR122U 203 - PN532 v1.4) is connected.

If I remember correctly this function is called in nfc.c, but I can't figure out what is going wrong.
System I'm using is openSUSE 11.4, mfoc-0.10.2, libnfc-1.4.2, libusb-1.0.8 and pcsc-lite-1.7.4.

-TM

The libnfc team is proud to announce major enhancements for the 1.6 serie, and development is moving forward quickly:
http://code.google.com/p/libnfc/updates/list

However, the core team is composed of GNU/Linux and FreeBSD hackers only, and some architecture changes totally broked the library down on Microsoft Windows. With no particular knowledge not interest in that Operating System, we are unfortunatelly unlikely to resurect it ourself, but we are aware that the Microsoft Windows support is a requirement for the libnfc.
We are therefore kindly requesting your contribution to port the changes we made to the library so that we can ship libnfc-1.6.0 with Microsoft Windows support.

If you like libnfc, use Windows and would like to contribute, feel free to write us a line!

Thanks!

The Libnfc Team

I've just registered here to tell you about some discovery. Me and my friend were stuck for like 3 hours digging what is wrong.
For support of ACS ACR122S (firmware 1.4) we downloaded latest svn commit r1314. When trying nfc-list we've seen that device returning not all characters, just pseudo apdu for SUCCESS "02 00 00 03". While sending manually command over serial was returning complete one with firmware bytes, as it was specified.
So here's the faii:

Index: libnfc/drivers/acr122s.c
===================================================================
--- libnfc/drivers/acr122s.c    (wersja 1314)
+++ libnfc/drivers/acr122s.c    (kopia robocza)
@@ -251,9 +251,9 @@
 acr122s_recv_frame(nfc_device *pnd, uint8_t *frame, size_t frame_size, void *abort_p, int timeout)
 {
   if (frame_size < 13)
-    pnd->last_error = NFC_EINVARG;
+  {  pnd->last_error = NFC_EINVARG;
     return pnd->last_error;
-
+    }
   int ret;
   serial_port port = DRIVER_DATA(pnd)->port;

Someone forgot the bloody brackets! :-D But that's not all. The leftover was a strange situation that we've seen about the command returned showing the success bytes result for pn53x_init, but it was claiming as fail.
Success was 0, so making negation of 0 gives 1, so True.

@@ -621,7 +621,7 @@
   }
 #endif
 
-  if (!pn53x_init(pnd)) {
+  if (pn53x_init(pnd)) {
     log_put(LOG_CATEGORY, NFC_PRIORITY_ERROR, "%s", "Failed initializing PN532 chip.");
     acr122s_close(pnd);
     return NULL;

After all that I was surprised, because with the lib mfoc was able to recover all keys. Unlike my previous trial with ACR122U (firmware 1.6) with Input/Output error while exploting, but I think it still might be fixed :-)

The TRF7970A uses either an SPI or parallel interface.

Gus S. Calabrese
99guspuppet

Working on Win XP SP3 and MacOSX:

Getting the revision R62, executing the win 32 binary from old-bin directory, works fine.
Compiling mfcuk using libnfc-1.5.1 dones not get any keys, on Win32 and MacOSX.

Anyone share the same experience ?

Regards,

I am using Mifare classic 1K card in one of my RFID based project for college.
I want to store register number of the student in the tag , so that the reader should read this number for authentication & link to his database in back-end PC .

I tried to change the ID of the Tag its not possible to change . reader will always reads the deafault ID (58C4E09C) .

How can I store the data in the  tag so that the reader  will read at the data ( register number )whatever i stored during authentication time.

Please help...
Regards,
Girish Kuamr