using Android phone I need read NDEF message (URI) from a microcontroller based NFC device. I read several standards like ISO/IEC 7816-4:2005, NFC Data Exchange Format (NDEF) and others. For now i have the following data exchange (crc bytes omitted when tx):
RX: 00 a4 04 00 07 d2 76 00 00 85 01 01 00 35 c0 // android selects file1
TX: 90 00
RX: 00 a4 00 0c 02 e1 03 d2 af //android selects file2
TX: 90 00
RX: 00 b0 00 00 0f 8e a6
TX: 00 01 02 03 04 05 06 07 08 09 //it is the dummy data
//here android restarts autocollision detection process
Maybe somebody can explain me the workflow of the commands. I dont know what file id means (file1= "d2 76 00 00 85 01 01" and file2= "e1 03")
I stopped at the first READ_BINARY command. i dont know what to send in response and where to read about this. I supposed that i need somehow insert the NDEF payload here. Also here another nfc topic
i found that the response to the first BO should be so called "capability container" but i dont know what is it, and it is not said in the NDEF specification.
The NFC spec for Type 4 cards is a good read
"d2 76 00 00 85 01 01" is the AID (Application ID) used for NDEF
"e1 03" is the Capability Container File ID
A summary of NDEF reading from a Type 4 card is:-
Select the NDEF AID
Select the Capability Container File ID
Read 15 Bytes of the Capability Container File
Select NDEF file ID
Read NDEF file
Capability Container File contains things like the File ID of the NDEF file, NDEF version number, NDEF read/write security, Maximum NDEF size,Maximum read sizes, etc.
All defined in the link of the NDEF spec I gave.
Here i found the description of the protocol NFC Forum Type 4 Tag IC with 16-Kbit EEPROM
Related
I am using plotly with python and I need the work week format to be from 00 to 52.
But the %V format from d3 is [01, 53], in fact, 00 is represented by 53.
The time format in this image is %V'%y
I have tried using lower case %v, but it doesn't work.
This creates a weird sorting error of where 53'10 is before 05'10. 53'10 should be 00'10
How to use 00 instead of 53?
Is there a customized way of formatting the tickers from 00 to 52?
One has to make a couple of adjustments to run the sample_wave.py example program on Python 3. But having made them and having sent a .wav file to the Voice endpoint I get:
b'HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nTransfer-Encoding: chunked\r\nConnection: close\r\n\r\n'b'e14\r\n{"Format":"SoundHoundVoiceSearchResult","FormatVersion":"1.0","Status":"Error","ErrorMessage":"Could not create speech handler because audio is not supported. (audio bytes received:
The audio bytes that followed the colon start with
\"52 49 46 46 62 27 24 5c 78 30 30 5c 78 30 30 5c 78 ...
Any suggestions?
Thanks in advance.
Cheers, Scott
It sounds like the audio file isn't supported, most likely because you need a header.
You can read more about supported formats here. https://www.houndify.com/docs#compressing-and-streaming-audio-formats
Best,
James
good afternoon
I can not connect the device
Here the data on it:
Full Speed device # 5 (0x14200000): Composite device: "FT240X USB FIFO"
Port Information: 0x001a
Not Captive
Attached to Root Hub
External Device
Connected
Enabled
Number Of Endpoints (includes EP0):
Total Endpoints for Configuration 1 (current): 3
Device Descriptor
Descriptor Version Number: 0x0200
Device Class: 0 (Composite)
Device Subclass: 0
Device Protocol: 0
Device MaxPacketSize: 8
Device VendorID/ProductID: 0x0403/0x6015 (Future Technology Devices International Limited)
Device Version Number: 0x1000
Number of Configurations: 1
Manufacturer String: 1 "FTDI"
Product String: 2 "FT240X USB FIFO"
Serial Number String: 3 "DA6LXJK"
Configuration Descriptor (current config)
Length (and contents): 32
Raw Descriptor (hex) 0000: 09 02 20 00 01 01 00 80 2D 09 04 00 00 02 FF FF
Raw Descriptor (hex) 0010: FF 02 07 05 81 02 40 00 00 07 05 02 02 40 00 00
Unknown Descriptor 0020:
Number of Interfaces: 1
Configuration Value: 1
Attributes: 0x80 (bus-powered)
MaxPower: 90 mA
Interface #0 - Vendor-specific "FT240X USB FIFO"
Alternate Setting 0
Number of Endpoints 2
Interface Class: 255 (Vendor-specific)
Interface Subclass; 255 (Vendor-specific)
Interface Protocol: 255
Endpoint 0x81 - Bulk Input
Address: 0x81 (IN)
Attributes: 0x02 (Bulk)
Max Packet Size: 64
Polling Interval: 0 ms
Endpoint 0x02 - Bulk Output
Address: 0x02 (OUT)
Attributes: 0x02 (Bulk)
Max Packet Size: 64
Polling Interval: 0 ms
when it is connected to the system should appear in the external (USB) audio device on which to send the sound settings
what should I do? write your kext? if so, how? where to start at all?
the manufacturer's website no drivers
A comprehensive answer to this question could probably fill a small book, but I'll try to give you some starting points.
USB Device Class Definition for Audio Devices
If the audio device adheres to the standard USB Audio Device class, but for some reason doesn't advertise this in the standard way, you can probably still use Apple's driver for such devices, by creating a codeless kext, or possibly a very small kext with some helper code.
There are a lot of details to this which Apple documents in TN2274 here.
Nonstandard USB audio
If your device uses a custom USB audio interface, you'll need to write your own driver. The kernel side API for this, IOAudioEngine etc. is actually deprecated since OSX Yosemite, with Apple recommending to write userspace Audio drivers instead. They provide some extensive sample code for getting started with this. Note that USB devices can be driven entirely from user space, so you don't even need a split USB/kernel driver architecture like you would for a PCI audio device.
I have an Identive Cloud 4710f reader.
I can "talk" with the reader but then I need to send a transparent ICC command and I cannot find a way to build a proper ADPU for that.
I need to send the PWD_AUTH command for NTAG21x ultralight ICCs that would be 0x1B followed by four bytes (the password).
I tried the envelope command FF C2 00 00 05 1B 00 00 00 00 00 envelope but, as much as it executes fine (9000 returned), the data is C0 03 00 6A 81 no matter what I send.
How do I send a transparent command with that reader?
Thank you.
I found a way to issue a transparent ICC command with the reader.
Documentation for the reader offers two commands:
TCL_PASS_THRU --> Does not work for it always returns me a "function in class not implemented" (?)
ISO14443_PART3_PASS_THRU --> This one works with a caveat.
So, the command APDU will be: FF EF 00 00 05 1B pw1 pw2 pw3 pw4
And it will return the NTAG PACK.
Please note that the response APDU will not contain the reader success return code (90 00) at all.
This information is relevant only for the Identive CLOUD readers.
Hope it helps.
Edoardo.
Recently I decided to look closer at the payload bytes of the tcpdump file format i.e. pcap, and I realized they don't make sense. These are collected on OS/X.
They absolutely always begin with 00 00.
Payload lengths are often around 39 bytes, 310 bytes, 1500 bytes.
Looking at the bytes, they often begin with 00 00 19 00 6f 08 00 00, or with 00 00 24 00 0b 00 0c 00.
They don't appear to begin with an Ethernet frame, an IP preamble, a UDP header, a TCP header, or any other expected data. When I search for my IPv4 MAC address within the data I often find it, but not always. Same with the IPv6 address. When I search for my IP address within the data, same deal.
Many of the packets seem to involve searching for or getting information about other Wifi networks.
Much of it seems to be operations to identify the (many) Wifi routers around me, but the format of that data is unknown to me.
Can anyone point me to a technical explanation of the payload bytes? Thanks.
I should also add that tcpdump itself has trouble reading these pcap files, which are generated on OS/X. The command to generate them is
/usr/sbin/tcpdump -s 0 -w output.pcap -vv -In -i en1
and the following command, which others recommended, does not properly dump them:
tcpdump -qns 0 -X -r output.pcap | less
In fact it generates lines that mention "tsft 1.0 Mb/s 2452 MHz 11g -78dB signal -91dB noise antenna 0 Beacon".
In fact it generates lines that mention "tsft 1.0 Mb/s 2452 MHz 11g -78dB signal -91dB noise antenna 0 Beacon".
What's wrong with that? It's dissecting radiotap headers in exactly the fashion it should.
You captured with the -I flag, meaning you captured in monitor mode. By default, on OS X (and, in most cases on Linux and *BSD), that captures with radiotap headers, giving radio-layer meta-data.
A pcap file has a "linktype" value in the file header; a pcap-ng file has a "linktype" value in each Interface Description Block for each network interface on which traffic was captured. Those values are described on the link-layer header types page of the tcpdump.org Web site. Your capture probably has a link-layer header type value of 127, which is LINKTYPE_IEEE802_11_RADIOTAP, and the packets begin with a radiotap header, followed by the 802.11 frame.
They absolutely always begin with 00 00.
That's the it_version field of the radiotap header, followed by the it_pad field; the only version of the radiotap header that currently exists is version 0, and the padding field is almost always if not always set to 0 (its value is irrelevant).
Looking at the bytes, they often begin with 00 00 19 00 6f 08 00 00, or with 00 00 24 00 0b 00 0c 00.
The 19 00 and 24 00 are the two-byte it_len field; it's little-endian, so 19 00 is 0x0019, or 25, and 24 00 is 0x0024, or 36. (19 00 is a bit suspicious, as it's not a multiple of 4.) That's the length of the radiotap header.