Trying to detect an iBeacon setup on raspberry PI using the android beacon library (with xamarin bindings)
Wondering what Im doing wrong here:
sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F 17 D1 AD 07 A9 61 00 01 00 00 C8 00
And setting up Beacon Parser like so
beaconManager.BeaconParsers.Add(new BeaconParser().SetBeaconLayout("m:0-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"));
I can detect this beacon with for example "BeaconScope" on Android but I can not get it detected using the android beacon library.
I can see the following output from debug
[BeaconParser] Processing pdu type FF: 02011a1aff4c000215e20a39f473f54bc4a12f17d1ad07a96100010000c80000000000000000000000000000000000000000000000000000000000000000 with startIndex: 5, endIndex: 29
[BeaconParser] Ignoring pdu type 06
[BeaconParser] This is not a matching Beacon advertisement. (Was expecting be ac. The bytes I see are: 02011a1aff4c000215e20a39f473f54bc4a12f17d1ad07a96100010000c80000000000000000000000000000000000000000000000000000000000000000
Setting up as AltBeacon works!
sudo hcitool -i hci0 cmd 0x08 0x0008 1F 02 01 1A 1B FF 18 01 BE AC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 C5 01
This one the library detects.
What am I missing?
I detect a RadButton setup as iBeacon but can not get it to work from raspberry PI
Try changing this:
"m:0-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"
to this:
"m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"
Note the first digit is a 2 instead of a 0
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.
I am developing a semi standard ibeacon, need to use the RSP broadcast field, I am using TI CC2541 broadcasting both Adv and RSP, working fine as from TI Packet Sniffer result attached.
I fail to get the RSP test data {0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF} scan on my Samsung Note3, Android 4.4.2, using example from http://developer.android.com/guide/topics/connectivity/bluetooth-le.html ,my added Log.d code is:
// Device scan callback.
private BluetoothAdapter.LeScanCallback mLeScanCallback =
new BluetoothAdapter.LeScanCallback() {
#Override
public void onLeScan(final BluetoothDevice device, int rssi, byte[] scanRecord) {
runOnUiThread(new Runnable() {
#Override
public void run() {
mLeDeviceListAdapter.addDevice(device);
mLeDeviceListAdapter.notifyDataSetChanged();
}
});
Log.d("Tag101: ", device.getAddress() + "||"+Integer.toString(rssi) + "||"+toHexadecimal(scanRecord));
}
};
Result:
10-15 21:07:28.066 19840-19853/com.example.android.bluetoothlegatt
D/Tag101:: 20:CD:39:B1:52:C2||-52||02 01 06 1a ff 4c 00 02 15 e2 c5 6d
b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 01 00 02 cd 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 10-15 21:07:28.286
19840-19840/com.example.android.bluetoothlegatt D/dalvikvm:
GC_FOR_ALLOC freed 514K, 13% free 10104K/11604K, paused 15ms, total
15ms 10-15 21:07:28.571
19840-19852/com.example.android.bluetoothlegatt D/BluetoothAdapter:
onScanResult() - Device=20:CD:39:B1:52:C2 RSSI=-52 10-15 21:07:28.571
19840-19852/com.example.android.bluetoothlegatt D/Tag101::
20:CD:39:B1:52:C2||-52||02 01 06 1a ff 4c 00 02 15 e2 c5 6d b5 df fb
48 d2 b0 60 d0 f5 a7 10 96 e0 00 01 00 02 cd 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 10-15 21:07:29.081 19840-2874/com.example.android.bluetoothlegatt
D/BluetoothAdapter: onScanResult() - Device=20:CD:39:B1:52:C2 RSSI=-51
10-15 21:07:29.081 19840-2874/com.example.android.bluetoothlegatt
D/Tag101:: 20:CD:39:B1:52:C2||-51||02 01 06 1a ff 4c 00 02 15 e2 c5 6d
b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 01 00 02 cd 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 10-15 21:07:29.581
19840-2873/com.example.android.bluetoothlegatt D/BluetoothAdapter:
onScanResult() - Device=20:CD:39:B1:52:C2 RSSI=-51
The Test Data can be scan correctly by TI Packet Sniffer:
enter image description here
Can anyone one advise on how to get the RSP in Android code, do I need to init scan-request?
Some example code will be great. Thanks.
Android normally requests a scan response all by itself, and when received, it appends the scanRecord with the PDU for the scan response. I see this is not happening in the scan record output you show.
You might try transmitting connectable advertisements and see if this makes a difference. It is possible Android only requests and processes the scan response for connectable advertisements.
try this Kotlin class to parse RSA data
also you could translate it to Java
finally you'll got a Map Array with all necessary RSA data
enum class EBLE {
EBLE_ZERO, // Zero element
EBLE_FLAGS, //«Flags» Bluetooth Core Specification:
EBLE_16BitUUIDInc, //«Incomplete List of 16-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_16BitUUIDCom, //«Complete List of 16-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_32BitUUIDInc,//«Incomplete List of 32-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_32BitUUIDCom,//«Complete List of 32-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_128BitUUIDInc,//«Incomplete List of 128-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_128BitUUIDCom,//«Complete List of 128-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_SHORTNAME,//«Shortened Local Name» Bluetooth Core Specification:
EBLE_LOCALNAME,//«Complete Local Name» Bluetooth Core Specification:
EBLE_TXPOWERLEVEL,//«Tx Power Level» Bluetooth Core Specification:
EBLE_DEVICECLASS,//«Class of Device» Bluetooth Core Specification:
EBLE_SIMPLEPAIRHASH,//«Simple Pairing Hash C» Bluetooth Core Specification:«Simple Pairing Hash C-192» Core Specification Supplement, Part A, section 1.6
EBLE_SIMPLEPAIRRAND,//«Simple Pairing Randomizer R» Bluetooth Core Specification:«Simple Pairing Randomizer R-192» Core Specification Supplement, Part A, section 1.6
EBLE_DEVICEID,//«Device ID» Device ID Profile v1.3 or later,«Security Manager TK Value» Bluetooth Core Specification:
EBLE_SECURITYMANAGER,//«Security Manager Out of Band Flags» Bluetooth Core Specification:
EBLE_SLAVEINTERVALRA,//«Slave Connection Interval Range» Bluetooth Core Specification:
EBLE_16BitSSUUID,//«List of 16-bit Service Solicitation UUIDs» Bluetooth Core Specification:
EBLE_128BitSSUUID, //«List of 128-bit Service Solicitation UUIDs» Bluetooth Core Specification:
EBLE_SERVICEDATA,//«Service Data» Bluetooth Core Specification:«Service Data - 16-bit UUID» Core Specification Supplement, Part A, section 1.11
EBLE_PTADDRESS,//«Public Target Address» Bluetooth Core Specification:
EBLE_RTADDRESS,//«Random Target Address» Bluetooth Core Specification:
EBLE_APPEARANCE,//«Appearance» Bluetooth Core Specification:
EBLE_DEVADDRESS,//«LE Bluetooth Device Address» Core Specification Supplement, Part A, section 1.16
EBLE_LEROLE,//«LE Role» Core Specification Supplement, Part A, section 1.17
EBLE_PAIRINGHASH,//«Simple Pairing Hash C-256» Core Specification Supplement, Part A, section 1.6
EBLE_PAIRINGRAND,//«Simple Pairing Randomizer R-256» Core Specification Supplement, Part A, section 1.6
EBLE_32BitSSUUID,//«List of 32-bit Service Solicitation UUIDs» Core Specification Supplement, Part A, section 1.10
EBLE_32BitSERDATA,//«Service Data - 32-bit UUID» Core Specification Supplement, Part A, section 1.11
EBLE_128BitSERDATA,//«Service Data - 128-bit UUID» Core Specification Supplement, Part A, section 1.11
EBLE_SECCONCONF,//«LE Secure Connections Confirmation Value» Core Specification Supplement Part A, Section 1.6
EBLE_SECCONRAND,//«LE Secure Connections Random Value» Core Specification Supplement Part A, Section 1.6
EBLE_3DINFDATA, //«3D Information Data» 3D Synchronization Profile, v1.0 or later
EBLE_MANDATA; //«Manufacturer Specific Data» Bluetooth Core Specification:
companion object {
private val map = EBLE.values()
fun fromInt(type: Int) = if (type > 0) map[type] else EBLE_MANDATA
fun getDistance(rssi: Int, txPower: Int) = {
/*
* RSSI = TxPower - 10 * n * lg(d)
* n = 2 (in free space)
*
* d = 10 ^ ((TxPower - RSSI) / (10 * n))
*/
Math.pow(10.0, (txPower.toDouble() - rssi) / (10 * 2))
}
/*
BLE Scan record parsing
*/
fun parseRecord(scanRecord: ByteArray): Map<EBLE, ByteArray> {
val ret = HashMap<EBLE, ByteArray>()
var index = 0
while (index < scanRecord.size) {
val length = scanRecord[index++].toInt()
//Zero value indicates that we are done with the record now
if (length == 0) break
val type = scanRecord[index].toInt()
//if the type is zero, then we are pass the significant section of the data,
// and we are thud done
if (type == 0) break
Arrays.copyOfRange(scanRecord, index + 1, index + length)?.let {
ret[EBLE.fromInt(type)] = it //HexUtil.formatHexString(it)
}
index += length
}
return ret
}
fun getServiceUUID(record: Map<EBLE, ByteArray>): String {
return when {
record.containsKey(EBLE.EBLE_128BitUUIDCom) -> {
val tmpString = HexUtil.formatHexString(record[EBLE.EBLE_128BitUUIDCom]?.reversedArray())
tmpString.substring(0, 8) + "-" + tmpString.substring(8, 12) + "-" + tmpString.substring(12, 16) + "-" + tmpString.substring(16, 20) + "-" + tmpString.substring(20, tmpString.length)
}
record.containsKey(EBLE.EBLE_32BitUUIDCom) -> {
HexUtil.formatHexString(record[EBLE.EBLE_32BitUUIDCom]?.reversedArray()) + "-0000-1000-8000-00805f9b34fb"
}
record.containsKey(EBLE.EBLE_128BitUUIDInc) -> { // Todo: Remove after bugfix !!!
val tmpString = HexUtil.formatHexString(record[EBLE.EBLE_128BitUUIDInc]?.reversedArray())
tmpString.substring(0, 8) + "-" + tmpString.substring(8, 12) + "-" + tmpString.substring(12, 16) + "-" + tmpString.substring(16, 20) + "-" + tmpString.substring(20, tmpString.length)
}
else -> {
"undefined"
}
}
}
fun getServiceUUID(scanRecord: ByteArray): String {
return getServiceUUID(parseRecord(scanRecord))
}
}
Gist link
I have solve the problem, I need to specified the length of scan_RSP:
// GAP - SCAN RSP data (max size = 31 bytes)
{
0x05, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE
};
Log.d result:
Device=20:CD:39:B1:52:C2 RSSI=-47 10-15 23:20:29.416
4780-4792/com.example.android.bluetoothlegatt D/Tag101::
20:CD:39:B1:52:C2||-47||02 01 06 1a ff 4c 00 02 15 e2 c5 6d b5 df fb
48 d2 b0 60 d0 f5 a7 10 96 e0 00 01 00 02 cd 05 aa bb cc dd ee 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 10-15 23:20:29.921 4780-4791/com.example.android.bluetoothlegatt
D/BluetoothAdapter: onScanResult() - Device=20:CD:39:B1:52:C2 RSSI=-47
10-15 23:20:29.921 4780-4791/com.example.android.bluetoothlegatt
D/Tag101:: 20:CD:39:B1:52:C2||-47||02 01 06 1a ff 4c 00 02 15 e2 c5 6d
b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 01 00 02 cd 05 aa bb cc dd
ee 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 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);
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.