Im having a problem with switching a Mifare Plus SE from SL1 to SL3, using acs acr122U with pn532
In SL1 the card is detected as a Mifare Classic (Same ATR) and to perform the switch i need to activate the comunication in 14443-4 and do the auth command with the SL3 switch key. I trying to activate the comunication in 14443-4, but im not finding how.
In other card which its already in SL3 (Also on SL1) the card is activated without problems in 14443-4 and i can send the mifare plus operations without problems.
Im using Smartcardio and transmitcontrolcommand to send the commands to the acr122U trying to use these commands from the PN532 :
-inAutoPoll (Which detects the card as 10 (mifare card, not 14443-4 card)
-InListPassiveTarget (Actives the card as mifare classic too)
-inATR (Which ends with a timeout)
I tryed to inRelease and reactivate again, is not working neither.
Thanks for your time
The problem you are facing is MFP in SL1 acts as a MFC, and does not advertise support for 14443-4 in its SAK. Most high-level libraries will simply not try to send RATS to switch to -4.
For MFP authentication command to work on 0x9001 (prerequisite for switching to SL3), you actually have to be in -4 mode, so you'll have to force sending RATS to get to -4, even if not advertised by card. Depending on your NFC library's API, this may not be possible.
For implementation in backend-agnostic code, I ended-up reimplementing -4 framing and using low-level communication APIs just for this case.
Once in SL3, -4 support is advertised, and switching happens transparently in most communication libraries.
Related
I am looking at implementing USB communication on a MCU which has a USB engine built into it. Basically you have access to the pipes/endpoints.
I am a little bit confused on the USB stack now. It appears that drivers operate on another level above the pipe/endpoint setup, so the pipe/endpoint is like a middle level layer that drivers are built on. Is this correct?
Secondly, I am interested in simulating serial communication over USB. It appears windows has a premade driver so on the computer side I do not need to program the pipe level.
How do I find out what I need to implement on the MCU to make it behave correctly with the generic serial driver?
This is an answer to your second question regarding the serial communication.
The USB standard defines a communication device class (CDC) for serial communication. The required drivers on the host side are implemented by Windows, macOS, Linux and many more operation systems.
The relevant CDC subclass is PSTN. The relevant documents are found in Class definition for Communication Devices 1.2.
The device basically implements four endpoints:
Control endpoint for configuration requests (baud rate, DTR state etc.). Have a look at SetLineCodeing, GetLineCoding and SetControlLineState.
Bulk endpoint for USB to serial transmission
Bulk endpoint for serial to USB transmission
Interrupt endpoint for notifications (DCD state, errors). See SerialState.
And of course you need to get the device descriptor right.
On top of that, you need to implement all the standard USB requests.
Chances are high that this has already been written for your MCU, both the standard requests and the serial communication. So why not use the existing code?
I am trying to integrate an RFID1356MIFARE, which uses NXP PN532, with an ESP32-EVB using their UART capabilities.
The NXP docs states that the PN532 is able to communicate on High Speed UART.
I am trying to use 38400 because that's the baud rate fixed by the reader that I'm using.
I've found a modified Adafruit PN532 library that added HSU support. This library states that HSU uses 115200 baud rate.
Now, I've modified PN532_HSU.cpp, where we can find:
void PN532_HSU::begin()
{
_serial->begin(115200);
}
into
void PN532_HSU::begin()
{
_serial->begin(38400, SERIAL_8N1, 36, 4);
}
Unfortunately, I haven't been able to establish communication between the reader and the ESP using this method.
I am able to get a readable output using normal Serial.read(), so UART communication works, but that's not how you read MIFARE cards.
I don't know what the problem is.
What do you think ?
[EDIT]
I went through the documentation and here is what i suggest: If you have a USB to serial device use it to directly connect reader module to computer else connect it directly using mini USB port in module. the follow following steps:
Put device in UART/ USB CDC mode depending on how you connected device to computer. Exact method to do this is provided in operation section of documentation
Use picoterm / screen or other serial terminal (if you are using Linux) or just use Arduino serial monitor with correct baud rate to connect device.(115200 for USB and 38400 for UART)
Type in commands listed in COMMAND SET FOR CDC AND UART MODE section in documentation to check if module is working or not.
Place some cards over reader to check what response does module sends when card is detected.
Use this information to develop your own library for reader.
It will not work with regular PN532 libraries. Instead you'll need to use regular Serial read and write to communicate.
[Original]
PN532 datasheet says host interface is selected by pulling up/down I0, I1 pins of device. For HSU both pins must be pulled down. This is implemented in hardware so you need to verify if the mode you want to use is set.
Looking into the link you posted for module, it says that it uses another micro-controller on board to extend communication capabilities, so maybe you need to use driver for that specific controller firmware? The link seems to have document explaining how to setup different communication system in Document section, please have a look there and check if it works.
Link: https://www.olimex.com/wiki/MOD-RFID1356MIFARE
When I insert a Smart Card to the reader after receiving ATR I can see in the driver log a number of IOCTL's that are not sent by my application (as is not running).
My question is if there is any document, describing Smard Card communication establishment in windows?
There is the Win32 API for communicating with smart cards within Windows
platform in form SCardXXX. Similar implementation for Linux is developed under
Muscle project as PC/SC Lite API.On Windows platform Following functions will be used:
SCardEstablishContext
SCardListReaders
SCardConnect
SCardReconnect
SCardDisconnect
SCardReleaseContext
SCardTransmit
Figure shows that how the smart card intract with application on windows platform.
For more information see the Here
I am writing my own program, which will be running on a 802.11 AP, to capture all the outgoing beacons on the AP. But I just noticed I cannot do it with the current libpcap: the program couldn't capture any outbound beacons. I've also tried Wireshark which gave the same result.
My questions are:
Can anyone shed some lights on the causes of what I saw?
Is there any user space method that I can capture the outbound beacons of a 802.11 AP on that specific AP (rather than capturing on other PCs)? It is better for me if I can do this without hacking into the wireless driver.
I am using Ubuntu 10.04 as the OS, Madwifi as the wireless driver.
Thanks, folks.
I would guess that the WiFi chip is generating the beacons autonomously
so they never pass the driver-chip interface where libpcap intercepts
packets. You'll probably need a second radio to be able to capture the
beacons from the air (when the primary radio is busy sending a beacon
the receiver is turned off so it can't hear what it is transmitting).
You can Capture those packets(Beacon ,Acknowledgement,etc) in wireshark
all you need to do is following :
go to capture menu
after selecting your interface go to option
select the per packet information option in link layer type of your interface
press start
So I have a bluetooth device, this device uses SPP to transfer data between the PC and itself. It connects fine through Windows as a bluetooth device. I can find it, enter the paring code and assign it to a COM port. Now I want to be able to send data through the com port using Windows API but it is refusing to do so.
I suspect that I need to setup the COMMCONFIG Structure correctly (see below)
http://msdn.microsoft.com/en-us/library/aa363188(VS.85).aspx
Unfortunately I have no idea what is the proper setting. I know SPP is supposed to emulate the RS-232 communication... so maybe I have to study up on that to figure out the right setting? Or is there some automatic way to set the COMMCONFIG structure.
I seriously doubt it. If it would be used then you'll have no chance at guessing at the custom provider data without docs from the driver author. Pay attention to the handshake signals, serial port devices routinely ignore anything sent to them when the DTR signal is turned off. And not send anything back with DTR off. A driver would emulate that. Use EscapeCommFunction() to turn them on. Also try a serial comm program like HyperTerminal or Putty to test this so you can isolate the source of the problem.
Why not use the Bluetooth sockets API? No need for troublesome (virtual) COM ports then.
If you're using managed code then see my library 32feet.NET
If using native code, use SOCKADDR_BTH with Winsock connect etc, see e.g. Bluetooth and connect (Windows) Then you can use the standard Winsock send/recv API
Ok, I found that you can use the
GetCommConfig and GetCommState functions to figure out the settings.