Please,
I am trying to write a simple Binary Block to mifare 1k tag with a ACR122U reader.
I am trying write to block 01, 5 bytes, text:'teste' and read it back.
But I always get an error 6300 when update this block.
Any thoughts?
I am using windows 8.1/delphi xe8.
My log is:
SCardEstablishContext succeeded.
Card State changed in ACS ACR122U PICC Interface 0 to available
New reader found: ACS ACR122U PICC Interface 0
Card inserted in ACS ACR122U PICC Interface 0
ATR = 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 01 00 00 00 00 6A
SCardConnect (shared) succeeded.
Active Protocol: T=1
ISO 14443 A, Part3 Card Type: Mifare Standard 1K is detected
Sending APDU to card: FF 82 00 01 06 FF FF FF FF FF FF
SCardTransmit succeeded.
Card response status word: 9000 (OK)
Sending APDU to card: FF 86 00 00 05 01 00 01 60 01
SCardTransmit succeeded.
Card response status word: 9000 (OK)
Sending APDU to card: FF 86 00 00 05 01 00 01 60 01
SCardTransmit succeeded.
Card response status word: 9000 (OK)
Sending APDU to card: FF D6 00 01 05 74 65 73 74 65
SCardTransmit succeeded.
Card response status word: 6300 (State of non-volatile memory changed.)
This is easily resolved by reading the documentation.
You're writing to a block and you have to provide a complete block of information. The only option for Lc is x04 or x10 - four bytes or sixteen bytes. For the Mifare 1K, it's prettly clear that you need to supply 16 bytes. You have only 5 bytes of data, so pad the rest with zeros.
| CMD | block1 | 16 bytes | data ...
FF D6 00 01 10 74 65 73 74 65 00 00 00 00 00 00 00 00 00 00 00
Related
I'm struggling with an old radiation sensor and his communication protocol.
The sensor is event driven, the master starts the communication with a data transmission or a data request.
Each data telegram uses a CRC16 to check only the variable data block and a CRC8 to check all the telegram.
My main problem is the crc16, According to the datasheet the poly used to check the data block is: CRC16 = X^14 + X^12 + X^5 + 1 --> 0x5021 ??
I captured some data with a valid CRC16 and tried to replicate the expected value in order to send my own data transmission, but I can't get the same value.
I'm using the sunshine CRC calculator trying any possible combination with that poly.
I also try CRC Reveng but no results.
Here are a few data with the correct CRC16:.
Data | CRC16 (MSB LSB)
14 00 00 0A | 1B 84
15 00 00 0C | 15 88
16 00 00 18 | 08 1D
00 00 00 00 | 00 00
00 00 00 01 | 19 D8
00 00 00 02 | 33 B0
01 00 00 00 | 5A DC
08 00 00 00 | c6 c2
10 00 00 00 | 85 95
80 00 00 00 | 0C EC
ff ff ff ff | f3 99
If I send an invalid CRC16 in the telegram, the sensor send a negative acknowledge with the expected value, so I can try any data in order to test or get more examples if needed.
if useful, the sensor uses a 8bit 8051 microprocessor, and this is an example of a valid CRC8 checked with sunshine CRC:
CRC8 = X^8 + X^6 + X^3 + 1 --> 0x49
Input reflected Result reflected
control byte | Data |CRC16 | CRC8
01 0E 01 00 24 2A 06 ff ff ff ff f3 99 |-> 0F
Any help is appreciated !
Looks like a typo on the polynomial. An n-bit CRC polynomial always starts with xn. Like your correct 8-bit polynomial. The 16-bit polynomial should read X16 + X12 + X5 + 1, which in fact is a very common 16-bit CRC polynomial.
To preserve the note in the comment, the four data bytes in the examples are swapped in each pair of bytes, which needs to be undone to get the correct CRC. (The control bytes in the CRC8 example are not swapped.)
So 14 00 00 0a becomes 00 14 0a 00, for which the above-described CRC gives the expected 0x1b84.
I would guess that the CRC is stored in the stream also swapped, so the message as bytes would be 00 14 0a 00 84 1b. That results in a sequence whose total CRC is 0.
I am trying to display the video my (PAUL) drone is sending to my over a UDP connection.
Frames look like (hexdump):
00 00 01 a1 00 1d 00 03
90 1a 00 00 a0 8a dc 0c
00 00 00 00 03 00 00 00
d0 02 40 02 00 04 00 00
90 1a 00 00 19 00 ......
Frames always start (trough my observation) with:
00 00 01 a
Are these NAL units?
I am want to display this in VLC player but don't know how to stream it to the VLC media player.
It looks a lot like a valid h.264 bitstream, but its not. 00 00 01 does look like a start code, But after a start code the first bit MUST be 0. a in binary is 1010 hence not valid.
I want to configure a Kollmorgen drive to rotate a motor with constant velocity via CANopen. I am using SDO mode for it.
My drive device id is 0614. So far I have configured it as:
Id=0614, Data= 2F 04 22 00 50 00 00 00 'Set run current to 80%
Id=0614, Data= 23 84 60 00 40 42 0F 00 'Set deceleration to 1M steps/sec^2
Id=0614, Data= 23 83 60 00 40 42 0F 00 'Set acceleration to 1M steps/sec^2
Enable motor power
Id=0614, Data= 2B 40 60 00 06 00 00 00 'Ready to Switch on
Id=0614, Data= 2B 40 60 00 07 00 00 00 'Switched on
Id=0614, Data= 2B 40 60 00 0F 00 00 00 'Operation Enable
Set to Profile Velocity Mode
Id=0614, Data= 2F 60 60 00 03 00 00 00 'Set to Profile Velocity Mode
Target Velocity -
Id=0614, Data= 23 FF 60 00 50 C3 00 00 'Target Velocity 50K
The problem I am facing is that whenever I am trying to enable the drive it gets disabled automatically. When I try to read StatusWord is gives 0270. Which means the device is disabled. It doesn't give any warning or fault.
the device Id in canopen protocol could not be bigger than 127. the COB ID of SDO download is 0x600+nodeID and the COB ID of SDO upload is 0x580+nodeID
I think the Id of your device is 0x14.also sdo DOWNLOAD message just include 4 bytes of data and the second third and fourth data are including the address OD 'S index and sub index that you want write to it and the first byte is specifier that is shown below
I am trying to filter packets where the 15th byte (i.e. the 1st payload byte after the 14 byte header) is a specific value, either 0x00 or 0x01.
The packets I am interested in are raw ethernet, i.e. at the logical-link control layer so I also filter on LLC as the protocol
Here is what I tried:
llc && (frame[14:1] == 00 || frame[14:1] == 01)
this comes up green so I'm pretty sure the syntax is correct. Its only displaying packets where Protocol is LLC but its also letting through packets where the 15th byte is 0x02 which I want to avoid
Any ideas how I can succesfully target the 15th byte value, or to put it another way, the 1st byte value of the payload?
example packet (copied from wireshark) where 15th byte is 0x00:
0000 01 01 01 01 01 01 02 02 02 02 02 02 00 0e 00 05 ................
0010 00 00 00 05 00 00 00 00 00 00 00 01 ............
example packet where 15th byte is 0x01:
0000 02 02 02 02 02 02 01 01 01 01 01 01 00 0a 01 05 ................
0010 00 00 00 0d 00 00 00 f1 00 00 00 00 00 00 00 00 ................
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 ............
I'd like to have wireshark display both these packets
There is a 3rd type of packet where the 15th byte is 0x02:
0000 02 02 02 02 02 02 01 01 01 01 01 01 00 39 02 ec .............9..
0010 41 61 02 a2 21 44 2b 0c 00 02 00 1c 0c 02 00 00 Aa..!D+.........
0020 00 00 00 00 00 00 00 00 00 00 00 ee 91 20 04 46 ............. .F
0030 22 44 2b cc 01 03 00 00 00 00 00 00 00 00 00 00 "D+.............
0040 00 00 00 00 00 00 00 .......
This type of packet I would like to exclude with the filter. My filter above still displays these 0x02 packets.
Here is the wireshark display filter requested:
llc and (frame[14] == 0 or frame[14] == 1)
Wireshark counts the first byte in each frame as byte 0, so the 15th byte is frame[14]. You do not need the colon for a single byte (as described in the docs). and and && are equivalent. or and || are also equivalent.
My wifi sniff device can output data to a raw file. But it may begin with the middle of a frame, and each frame starts right after another. A pcap file must contain packet headers, which I don't have. So I tried to discard the half complete frame at the beginning of the file, and put the rest into a pcap file with one packet. Then wireshark can analyze the first frame, even with wrong packet size.
My question is how to make wireshark analyze the remaining frames ?
Edit: This is a sample pcap with 2 frame, but without the second packet header
00000000 D4 C3 B2 A1 02 00 04 00 00 00 00 00 00 00 00 00 Ôò¡............
00000010 FF FF 00 00 69 00 00 00 05 00 00 00 00 00 00 00 ÿÿ..i...........
00000020 80 00 00 00 80 00 00 00 08 02 00 00 01 00 5E 00 €...€.........^.
00000030 00 FC E8 94 F6 3C 5F 40 20 68 9D 9A 4B D7 70 73 .üèâ€Ã¶<_# h.Å¡K×ps
00000040 AA AA 03 00 00 00 08 00 46 00 00 20 38 F8 00 00 ªª......F.. 8ø..
00000050 01 02 48 D5 C0 A8 01 66 E0 00 00 FC 94 04 00 00 ..HÕÀ¨.fà ..üâ€...
00000060 16 00 09 03 E0 00 00 FC 08 02 00 00 01 00 5E 7F ....à ..ü......^.
00000070 FF FA E8 94 F6 3C 5F 40 20 68 9D 9A 4B D7 F0 75 ÿúèâ€Ã¶<_# h.Å¡K×ðu
00000080 AA AA 03 00 00 00 08 00 46 00 00 20 38 F9 00 00 ªª......F.. 8ù..
00000090 01 02 39 D6 C0 A8 01 66 EF FF FF FA 94 04 00 00 ..9ÖÀ¨.fïÿÿúâ€...
000000A0 16 00 FA 04 EF FF FF FA ..ú.ïÿÿú
My question is how to make wireshark analyze the remaining frames ?
Detect the beginnings and ends of frames in your bit sequence, and put each frame into a separate record in the pcap file.
If there's nothing in the bit sequence to allow your software to determine where one frame ends and another frame begins, there's nothing in the bit sequence to allow Wireshark to do so, so if you want to have Wireshark analyzer frames past the first frame, you are FORCED to ensure that there's something in the bit stream to determine frame boundaries, and you might as well have your software break the bit stream into frames.