Develop Reference

Open Mobile API & Extended logical channel

I'm currently working a project with Open Mobile API. Basically, I got this problem when i exchange apdu to the UICC, all my commands converted automatically to the extended logical APDU command (CLA : 0xC1). I'm using Samsung Galaxy S6 Edge during this test with android version : 5.0.2.
APDU > Header [CLA INS P1 P2] 00 70 00 00 194,69 etu MANAGE CHANNEL
< Outgoing data 01
< Return code [SW1 SW2] 90 00
APDU > Header [CLA INS P1 P2] 01 A4 04 00 194,69 etu SELECT
Incoming data A0 00 00 05 59 10 10 FF FF FF FF 89 00 00 01 00
< Outgoing data 6F 1A 84 10 A0 00 00 05 59 10 10 FF FF FF FF 89
00 00 01 00 A5 06 73 00 9F 65 01 FF
< Return code [SW1 SW2] 90 00
APDU > Header [CLA INS P1 P2] C1 E2 91 00 187,69 etu
Incoming data BF 2D 00
< Return code [SW1 SW2] 6D 00
APDU > Header [CLA INS P1 P2] 00 70 80 01 192,69 etu MANAGE CHANNEL
< Return code [SW1 SW2] 90 00
What could be a problem? Who is responsible to change my CLA command to 0xC1? Why the phone change the CLA command to 0xC1?
Note : Based on my application log, I send this 81 E2 91 00 02 BF 2D 00
Thanks for your help.

Radiusnetwork Sample for make RaspberryPi as a Ibeacon device failed

Followed by the sample, I started my Pi with the command:
pi#raspberrypi ~ $ sudo hciconfig hci0 up
pi#raspberrypi ~ $ hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:71:13 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING
RX bytes:1094 acl:0 sco:0 events:54 errors:0
TX bytes:768 acl:0 sco:0 commands:54 errors:0
pi#raspberrypi ~ $ sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
< HCI Command: ogf 0x08, ocf 0x0008, plen 44
1E 02 01 1A 1A FF 4C 00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60
D0 F5 A7 10 96 E0 00 00 00 00 C5 00 00 00 00 00 00 00 00 00
00 00 00 00
> HCI Event: 0x0e plen 4
01 08 20 12
pi#raspberrypi ~ $ sudo hciconfig hci0 leadv 3
Then, turned on my Android 4.4 phone which works perfectly with the Ibeacon devices I ordered from online retailers(no brand).
works perfectly means I can see all the advertising data in Java code(by following onLeScan(...) callback), as well as the RSSI, and parsing them(UUID, major, minor and etc.).
The strange thing is I put a debug info into:
public synchronized void onLeScan(final BluetoothDevice device,
int rssi, byte[] scanRecord)
the byte[] scanRecord I got from PI is:
02 01 0A 02 0A 08 0C 09 43 53 52 38 35 31 30 20 41 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I can't read these bytes which seems totally mismatched with the one set via Pi command line, I tried with the App IBeacon Locate, still couldn't find my Pi, please help, thanks.
Add more details:
Only the BLE dongle is a different brand from the sample since I'm not in US, and I'm not sure if its drivers were installed correctly in PI and actually I didn't explicitly installed any drivers for it(I'm a new guy for Linux), I just pulg in and started the command line.

Some folks with different bluetooth dongles have reported having to alter the order of the commands and disabling advertising before enabling it. Try:
sudo hciconfig hci0 up
sudo hciconfig hci0 noleadv
sudo hciconfig hci0 leadv
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
You might also let us know the model of your bluetooth dongle and what it reports itself as to Linux. You can see this by typing lsusb
BTW, nice job capturing the bytes read by Android's onLEScan method. Super helpful!

Android NFC writeNdefMessage throws IOException Tag is not ndef

I'm developing a NFC environment consisting of a tag (AS3953 chip + microcontroller) and a smartphone (Samsung Galaxy Fame runnung Android 4.1.2).
While reading a NDEF message works I'm stuck on writing the message to the tag.
I copied most of the code from http://tapintonfc.blogspot.de/2012/07/the-above-footage-from-our-nfc-workshop.html
and modified it to accept ISO14443A Tag Type 4 by searching the tag techlist for IsoDep, NfcA and Ndef in supportedTechs().
Since all of them are listed the app continues to writeTag():
public WriteResponse writeTag(NdefMessage message, Tag tag) {
try {
Ndef ndef = Ndef.get(tag);
if (ndef != null) {
Log.d(TAG, "writeTag: tag type: "+ndef.getType());
ndef.connect();
Log.d(TAG, "writeTag: connected!");
if (!ndef.isWritable()) {
return new WriteResponse(0, "Tag is read-only");
}
if (ndef.getMaxSize() < message.toByteArray().length) {
return new WriteResponse(0, "size error");
}
Log.d(TAG, "writeTag: write ndef...");
ndef.writeNdefMessage(message);
Log.d(TAG, "writeTag: wrote ndef!");
if (writeProtect)
ndef.makeReadOnly();
return new WriteResponse(1, "Wrote message to pre-formatted tag.");
} else {
Log.d(TAG, "writeTag: ndef==null!");
return new WriteResponse(0, "writeTag: ndef==null!");
}
} catch (Exception e) {
Log.d(TAG, "writeTag: exception: " + e.toString());
return new WriteResponse(0, "Failed to write tag");
}
}
LogCat shows:
11:08:46.400: onNewIntent
11:08:46.400: supportedTechs: techlist: android.nfc.tech.IsoDep,android.nfc.tech.NfcA,android.nfc.tech.Ndef,
11:08:46.400: supportedTechs: tech is supported!
11:08:46.400: writeTag: tag type: org.nfcforum.ndef.type4
11:08:46.410: writeTag: connected!
11:08:46.410: writeTag: write ndef...
11:08:46.490: writeTag: exception: java.io.IOException: Tag is not ndef
As you can see an IOException is thrown saying the Tag is not ndef which contradicts
the techlist. Looking further into the android code writeNdefMessage() tries to get
a TagService and a ServiceHandle from the tag to match them against. This fails so
the exception is thrown (no message written up to now):
public void writeNdefMessage(NdefMessage msg) throws IOException, FormatException {
...
INfcTag tagService = mTag.getTagService();
...
int serviceHandle = mTag.getServiceHandle();
if (tagService.isNdef(serviceHandle)) {
...
}
else {
throw new IOException("Tag is not ndef");
}
...
}
Is there a workaround for that or is it not possible at all with my kind of tag?
As I'm also programming the tag the error might be on the other side, but it
seems to be a Java problem.
Edit 1:
I don't connect to any technology before so there shouldn't be any opened connection. If
I open an connection before ndef.connect() there is IllegalStateException: Close other technology first!
I configured AS3953 to ISO14443A Level-4 so only Tag Type 4 Blocks are forwarded
to the microcontroller. Only I-Blocks are handled but even if there are other commands the µC has to read it out
over the SPI port which isn't the case by logic analysis. As I said reading the ndef file works and I tested it
for a 4KB file. Looking at the logic analysis the following steps are made (all returning a positive 9000-code):
(c=command, r=response) (corrected due to renaming mistake)
select by name:
c: 02 00 a4 04 00 07 d2 76 00 00 85 01 01 00
r: 02 90 00
select by id - select cc file
c: 03 00 a4 00 0c 02 e1 03
r: 03 90 00
read 0x0f bytes of cc file
c: 02 00 b0 00 00 0f
r: 02 00 0f 20 00 3b 00 34 04 06 e1 04 0f ff 00 00 90 00
select by id - select ndef file
c: 03 00 a4 00 0c 02 e1 04
r: 03 90 00
read 0x02 bytes (first 2 bytes are apdu-size)
c: 02 00 b0 00 00 02
r: 02 0f d3 90 00
read 0x3b bytes (frame size) of first part of ndef file (external type, jpeg image as payload)
c: 03 00 b0 00 02 3b
r: 03 c4 0c 00 00 0f c1 64 65 2e 74 65 73 74 61 70 70 3a 61 01 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 60 00 60 00 00 ff db 00 43 00 49 32 36 40 36 2d 49 40 3b 40 52 4d 49 56 6d 90 00
[ndef file]
read 0x26 bytes of last part of ndef file
c: 03 00 b0 0f ae 27
r: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 FF D9 00 00 90 00
Using the same app for writing I start the activity which filters NfcAdapter.ACTION_TAG_DISCOVERED intents.
Just as in the linked example the phone touches the tag calling onResume() doing
mNfcAdapter.enableForegroundDispatch(...);
When I log the SPI communication the same reading procedure as above is done. Since LogCat
shows a working intent dispatcher I guess the app stops at the IOException, closing the connection
and immediately going over to read out as android found the tag again.
Edit 2:
There might be a hint as one of the first interrupts issue a deselect command
which is handled by AS3953 itself:
(count * interrupt)
3 * power up
1 * Wake-up IRQ at entry in ACTIVE(*) state
1 * Deselect command
1 * Wake-up IRQ at entry in ACTIVE(*) state
1 * IRQ due to start of receive

It works now. I figured out that a startup routine which checks and sets the configuration word
was transmitted with a too high baud rate for the AS3953. This worked for reading but something
must have been mixed up for writing to the tag.
I cannot tell for sure if this is the only reason why it didn't work. There is also a problem
with slow reading of the 32Byte FIFO as waterlevel interrupts are handled too late - I simply expected
the problem to be on the android side since I couldn't find the write command in the logic analysis
and the exception didn't describe the reason enough.
Thanks a lot to Michael Roland for further debugging, I still don't unterstand why the tag is
read at first if I want to write to it but well - there should be a workaround reading an
empty ndef message so the writing process will be done quickly.
For now I have to work on the firmware and cannot forecast any further problems but the actual
issue (ndef.writeNdefMessage()) returns successfully.

Decoding a binary file

I am using the following code to read a structured binary file
FileInputStream objIS = new FileInputStream("/sdcard/waverider.usr");
DataInputStream objBR = new DataInputStream(objIS);
objwVer = objBR.readShort();
objwSVer = objBR.readShort();
objNoWaypoints = objBR.readShort();
System.out.println(objwVer);
System.out.println(objwSVer);
System.out.println(objNoWaypoints);
objIS.close();
This produces the result:
512
0
8706
The result I am after is
2
0
546
That is what I get with VB.net using:
objwVer = objBR.ReadInt16
objwSVer = objBR.ReadInt16
objNoWaypoints = objBR.ReadInt16
The binary file is as follow:
02 00 00 00 22 02 00 00 4b a9 c8 ff b2 2d 33 00
00 00 00 00 04 00 00 00 48 6f 6d 65 00 00 00 00
1c 68 53 0d 10 27 00 00 00 00 01 00 7e 8c c8 ff
Am I missing something here
9d 33 33 00 00 00 00 00 06 00 00 00

Your problem is that
your file is written in little endian byte order but your code is expecting big endian byte order.

Your stream is encoded in little-endian and DataInputStream only supports big-endian.
You could use ByteBuffer instead, which allows to parse little-endian formatted stream: http://developer.android.com/reference/java/nio/ByteOrder.html#LITTLE_ENDIAN

try JBBP framework, it is android compatible and its JBBPBitInputStream allows read data in different byte and bit order
new JBBPBitInputStream(in).readInt(JBBPByteOrder.LITTLE_ENDIAN);

Gmail on Android corrupt some files

In one of my application, I open binary files, and I got some error report by users on some files. When they send me the files, if I download them on Gmail in the desktop, the file displays nicely in my app. When I download them with the native Android GMail app, the file doesn't open.
Here are the first 64 bytes of the original file, and as it appear when downloaded from the desktop (displayed as hexa):
03 00 08 00 D8 0C 00 00 01 00 1C 00 BC 02 00 00
2D 00 00 00 00 00 00 00 00 01 00 00 D0 00 00 00
00 00 00 00 00 00 00 00 10 00 00 00 25 00 00 00
33 00 00 00 3D 00 00 00 44 00 00 00 49 00 00 00
And here are the first 64 bytes of the file downloaded with the native GMail app (hexa again) :
EF BF BD EF BF BD 2D EF BF BD 25 33 3D 44 49 4D
52 63 72 76 EF BF BD EF BF BD EF BF BD EF BF BD
EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF
BF BD EF BF BD 29 2E 3E 43 54 59 69 6E 7F EF BF
Is there a sort of compression applied to this file or is the GMail app corrupting it ? Especially if you look at the end of the first sample, you have the following bytes 10, 25, 33, 3D, 44, 49, which also appear in the first line of the second sample, which leed me to think that it's a compression of some sort.

I'm not sure of the exact source, but if you look at http://www.cogsci.ed.ac.uk/~richard/utf-8.cgi?input=%F6&mode=char then that pattern is due to something trying to interpret the file as UTF-8, doing replacement, then writing the file as UTF-8.