Mifare Classic 4K Authentication failed- how to make it Work? - nfc

I am very new to the 14443A protocol and mifare Clasic 4k Tag. I have a TRF7960A RFID reader interfaced to my device which is supporting Mifare mode after reading the Firmware version.
I got some information from my vendor but still i am facing issue in authentication.
I have pasted the Commands send and received in below.
Can any one help me in this about how the packet is being created?
Thanks in advance
Jethin
Set to Mifare Mode
Send : 0108000304FD00000
Returned : 108000304FD0000
Firmware Version 3.3[Mode Mifare]
Set Protocol
Send : 010A0003041000010000
Returned : 010A0003041000010000
Register write request.
Send : 010C00030410002101080000
Returned : 010C00030410002101080000
Register write request.
Send : 0109000304F0000000
Returned : 0109000304F0000000
Send : 0109000304F1FF0000
Returned : 0109000304F1FF0000
Scan Card UID
Send : 0109000304A0010000
Returned : 0109000304A0010000
14443A REQA.
(0200)(DB24C7A69E)[DB24C7A69E]
Received UID is DB24C7A69E
Authicate Block 04 Key is FFFFFFFFFFFF UID is DB24C7A69E
Send : 010A0003041850000000
Returned : 010A0003041850000000
Request mode.
[]
Send : 010D000304A2DB24C7A69E0000
Returned : 010D000304A2DB24C7A69E0000
14443A Select.
(0200)[18]
Send : 010E000304C0FFFFFFFFFFFF0000
Returned : 010E000304C0FFFFFFFFFFFF0000
Crypto1 set key.
Initialization ok
Send : 010F000304C16004DB24C7A69E 0000
Returned : 010F000304C16004DB24C7A69E 0000
Crypto1 authentication step 1.
!! 00 bytes and 00 bits received, expected 4 bytes and 0 bits. Abort
Send : 010C000304C23D6E98990000
Returned : 010C000304C23D6E98990000
Crypto1 authentication step 2.ý
Read Block 04 DATA
Send : 010A000304C830040000
Returned : 010A000304C830040000
Encrypted request mode.
!! cipher not initialized. Abort
Write Block 04 Write Data 12345678123456781234567812345678
Send : 010A000304C8A0040000
Returned : 010A000304C8A0040000
Encrypted request mode.
!! cipher not initialized. Abort
Send : 0118000304C8123456781234567812345678123456780000
Returned : 0118000304C8123456781234567812345678123456780000
Encrypted request mode.
!! cipher not initialized. Abort

A MIFARE Classic UID is always 4 bytes or 7 bytes, never 5 bytes. I don't know the TRF7960A, but I suspect that your problem is related to this. It would make the authentication fail: the tag will simply not answer. Any following commands requiring a successful authentication will also not work.

Related

Unable to receive URC for an incoming SMS from a modem

I have an issue in being unable to recive the URC message from the modem whenever it receives an SMS.
I know that it receives them since i can find and read them if I use AT+CMGL but, i don't receive any notification when the modem gets them. I played around with the URC related commands but I've been unable to get it to work (other URCs work fine).
The modem is a BG600L M3 from Quectel and following is the sequence of commands i'm sending ("AT" is always omitted and the first command is literally "AT\r", basically an empty one).
//general config
AT\r
CFUN=1,0
E1
+QCFG=\"urc/ri/other\",\"pulse\",8,1
H0
&F
V1
+CMEE=1
&D0
E1
+CREG=2
+CGREG=2
+CEREG=2
//sms config
+CPMS=\"ME\",\"ME\",\"ME\"
+QINDCFG=\"smsincoming\",1
+CMGF=1
+CSDH=0
+CSCS=\"GSM\"
+CNMI=2,2,0,2,0
//doing some deleting and reading
+CMGD=1,3
+CPMS?
//getting the gps fix
+QGPS=1
+QGPSCFG=\"gnssconfig\",3
+QGPSLOC=1
+QGPSEND
//resetting the gms connection
+CFUN=0
+CFUN=1,0
//setting up the gsm connection
+QICFG=\"dataformat\",0,0
+QICFG=\"viewmode\",0
+QICFG=\"recvind\",1
+QICFG=\"tcp/retranscfg\",3,600
+QISDE=0
+QCFG=\"band\",0xf,0x80085,0x80085,1
+QCFG=\"nwscanmode\",1,1
+QCFG=\"nwscanseq\",010101,1
+QCFG=\"iotopmode\",2,1
// checking if it's connected
+CREG?
+QNWINFO
+COPS?
//Getting the time
+CTZU=3
+CTZR=0
+QLTS
+CCLK?
You can set AT+CNMI=2,1,2,0,0 , that should do the trick.
According to specification ETSI TS 127 005 V11.0.0 (2012-10)
+CNMI: <mode>,<mt>,<bm>,<ds>,<bfr>
by keeping <mt> value to 1 we should get indication when message is stored in ME/TA
<mt>: integer type (the rules for storing received SMs depend on its
data coding scheme
0 No SMS-DELIVER indications are routed to the TE.
1 If SMS-DELIVER is stored into ME/TA, indication of the memory location is routed to the TE using unsolicited result code:
+CMTI: <mem>,<index>

Send message from HC 05 Module to another not working

I'm trying to send messages from a HC-05 arduino module to another following this tutorial : https://www.youtube.com/watch?v=mC8HDjRdcso
but with arduino uno's instead of nano's.
The AT configuration works fine but when I try to send messages it doesn't work and I don't know why.
The code is here : https://github.com/stechiez/Arduino/tree/master/HC05_master_Slave
(i've changed the RX, TX pins to 10,11 and of course the hc 05 adress is not the same)
This is how I've connected one hc 05 module to the arduino and the other one is the same.
And this is the output I have on the serials :

Error: Invalid number format while sending SMS with SIM800L

I'm using a SIM800L GSM module connected over USB-Serial to my computer.
When I try to send a SMS I got an error:
AT+CMGS="+4915xxxxxxxxx"
> Test (Ctrl+Z)
+CMS ERROR: Invalid number format (incomplete number)
I’m obviously connected to the network because pin is entered +CREG an +COPS seems good.
AT+CPIN?
+CPIN: READY
OK
AT+CREG?
+CREG: 0,1
OK
AT+COPS?
+COPS: 0,0,"O2 (Germany)"
OK
As well I can receive SMS and see incoming calls.
I set the module in sms text mode and use the coding GSM
AT+CMGF?
+CMGF: 1
OK
AT+CSCS?
+CSCS: "GSM"
OK
I try different number formats like "015xxxxxxxxx" or "004915xxxxxxxxx". Also I try different values for the optional parameter from +CMGS
Could anybody advise me what to do?
To send SMS it was necessary for me to change the SMSC adress with the command AT+CSCA.
AT+CSCA="+491760000443",145
The SMSC you can found at your mobile operator. In my case Netzclub at O2 Germany.

ZPL ^HS command gives incorrect value for number of formats in receive buffer

I am trying to get the number of label formats remaining in the print buffer of a Zebra printer. The printer is being accessed using the Zatar cloud service. To achieve this I am:
putting the printer in a paused state
calling the ^HS command
looking at the 5th field in string 1 of the response
According to the ZPL documentation this field is the
number of formats in receive buffer
However, this value does not appear to be correct. Each subsequent time we call it whilst the printer is paused the value in the field increases. No other jobs are being sent to the printer.
Here is same output of the response:
DEVICE_COMPLETED_SUCCESSFULLY - 030,0,1,0834,003,0,0,0,000,0,0,0
000,0,0,0,0,2,6,0,00000001,1,001
1234,0
Then this after a short interval:
DEVICE_COMPLETED_SUCCESSFULLY - 030,0,1,0834,026,0,0,0,000,0,0,0
000,0,0,0,0,2,6,0,00000001,1,001
1234,0
And so on:
DEVICE_COMPLETED_SUCCESSFULLY - 030,0,1,0834,028,0,0,0,000,0,0,0
000,0,0,0,0,2,6,0,00000001,1,001
1234,0
The initial response of 003 is correct. However I do not understand why it is then incrementing to 26 and then to 28.
Why is the response not providing the correct value for the formats remaining in the receive buffer?
The reason for the discrepancy in the number of formats in the receive buffer was due to how the printer was being accessed. The Zatar cloud service was used rather than any direct method such as USB.
The Zatar cloud service uses a device called an Edgebox to communicate with the printer. The Edgebox was periodically sending commands to the printer and it was these commands that were accumulating in the receive buffer.

APNS response packet returning the wrong identifier

I'm getting an odd error when using APNS under production.
Whenever I send a notification that errors (for example the device token becomes invalid), the response packet returned is correct, except that the identifier is 1 less than the identifier I sent. However, on production the correct identifier is returned.
For example: I send a notification with ID 108. But I receive a packet back:
8 8 0 0 0 107
The first byte will always be 8
The second byte is the status code; in this case meaning the device token isn't valid
The last 4 bytes are the identifier
For convenience, here is Apples documentation on the subject.
http://developer.apple.com/library/ios/#DOCUMENTATION/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingWIthAPS/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW4
Is anyone else seeing this problem, or is it likely something I've done wrong.
Many thanks in advance.

Resources