Bluetooth LE getting RSSI Vaule on Raspberry Pi2 - raspbian

I'm trying to get the TxPower(RSSI) Value of an iBeacon (BEACONinside, ModelNo. B0001-A) and I'm struggling to get this value into a Python-, C- or Shellscript.
I looked through many Tutorials and Stackoverflow Questions, but (since BLE is quiet new) I'm not able to find anything to start with.
I'm able to get the data on the commandline with
sudo hcitool lescan
and
sudo hcidump -a | egrep 'RSSI|bdaddr XX:XX:XX:XX'
But I'm getting also the RSSI value of an BLE-device with status 'random', and no further information for it. My knowledge of regular expressions is pretty limited and so i don't know how i can get only the Data from the device I want.
And as said at the top i would like to get this information into a script so I can use it for further actions.
EDIT:
Here is the output of the hcidump:
bdaddr 20:C3:8F:D1:0E:B1 (Public)
RSSI: -28
bdaddr 20:C3:8F:D1:0E:B1 (Public)
RSSI: -28
bdaddr 20:C3:8F:D1:0E:B1 (Public)
RSSI: -31
bdaddr 20:C3:8F:D1:0E:B1 (Public)
RSSI: -32
bdaddr 20:C3:8F:D1:0E:B1 (Public)
RSSI: -28
bdaddr 20:C3:8F:D1:0E:B1 (Public)
RSSI: -28
bdaddr DD:45:C9:26:61:51 (Random)
RSSI: -57
bdaddr DD:45:C9:26:61:51 (Random)
RSSI: -60
bdaddr 20:C3:8F:D1:0E:B1 (Public)
RSSI: -29
I know the bdaddr of the devices i want to scan for. so I would like to get only the RSSI for these devices.
Glad for any help

Related

OpenSC fails to connect javacard with PKCS applet

I have empty JavaCOS A40 smartcard and want make it a PKCS PKI card.
I'm going to use it as ssh key and for e-contracts signing. Russia don't provide smartcard-based e-id for citizens like EU countries do. Commercial e-signature providers are selling some sort of password-protected usb drives, that's unsafe to use, because you can easily export private key. Also they sell normal smartcards, but they are really expensive(x10-x20 than empty javacard) and short-living(about 1 year). So i want to make my own PKI card based on RSA algorhitms from javacard.
Now my javacard is in state OP_READY and I don't changed it, because changes are irreversible. It use default key and anyone can upload anything. I use ACR38U reader with pcsc linux driver on Ubuntu and it works as expected, so I used GlobalPlatformPro to upload PKI IsoApplet as default. So GP's output:
java -jar gp.jar -list
Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
ISD: A000000003000000 (OP_READY)
Privs: SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement
APP: F276A288BCFBA69D34F31001 (SELECTABLE)
Privs: CardReset
PKG: F276A288BCFBA69D34F310 (LOADED)
Version: 1.0
Applet: F276A288BCFBA69D34F31001
cardpeek successfully connects to it and I can send low-level commands to applet
But when I try to connect to card and applet using opensc prober to see Answer-To-Request(ATR), it fails opensc-tool --reader 0 --atr. See maximum debug info
Shortened version:
opensc-tool --reader 0 --atr -vv
Connecting to card in reader ACS ACR 38U-CCID 00 00...
0x7fc849e7e740 22:17:14.634 [opensc-tool] card.c:200:sc_connect_card: called
0x7fc849e7e740 22:17:14.634 [opensc-tool] card-entersafe.c:138:entersafe_match_card: called
Failed to connect to card: Card command failed
0x7fc849e7e740 22:17:14.797 [opensc-tool] ctx.c:870:sc_release_context: called
According to manufacturer info, card is supporting T=0 over ISO7816, but opensc tries to communicate with T=1. So how I can fix this?
Seems, that opensc tools are not customizable. I need to use pkcs15-crypt, but it can't connect. May I change drivers, recompile opensc with patches, or use another utility? How another ways I can use to work with OpenPGP for example?
Your problem is certainly not with the transport protocol because it communicates an APDU with the card. When looking at the logging it seems to incorrectly guess from the ATR that the card is an epass2003:
0x7f175a21e740 22:14:13.904 [opensc-tool] card.c:287:sc_connect_card: matched: epass2003
then execute a command to it:
0x7f175a21e740 22:14:13.904 [opensc-tool] apdu.c:378:sc_single_transmit: CLA:0, INS:CA, P1:1, P2:86, data(0) (nil)
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:283:pcsc_transmit: reader 'ACS ACR 38U-CCID 00 00'
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:284:pcsc_transmit:
Outgoing APDU (5 bytes):
00 CA 01 86 00 .....
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:212:pcsc_internal_transmit: called
0x7f175a21e740 22:14:13.912 [opensc-tool] reader-pcsc.c:293:pcsc_transmit:
Incoming APDU (2 bytes):
6D 00 m.
0x7f175a21e740 22:14:13.912 [opensc-tool] apdu.c:390:sc_single_transmit: returning with: 0 (Success)
0x7f175a21e740 22:14:13.912 [opensc-tool] apdu.c:543:sc_transmit: returning with: 0 (Success)
0x7f175a21e740 22:14:13.912 [opensc-tool] card.c:459:sc_unlock: called
0x7f175a21e740 22:14:13.912 [opensc-tool] reader-pcsc.c:662:pcsc_unlock: called
0x7f175a21e740 22:14:13.921 [opensc-tool] card-epass2003.c:189:epass2003_check_sw: Instruction code not supported or invalid
0x7f175a21e740 22:14:13.921 [opensc-tool] card-epass2003.c:1118:get_data: get_data failed: -1204 (Unsupported INS byte in APDU)
Now this command is executed over the communication channel in T=1 (it's very unlikely that the card just supports T=0 if it also supports T=CL, because T=CL and T=1 are very much alike - at the higher level). Not only that, it correctly returns a result, even if that is higher level error condition: 6D00 meaning instruction not supported.
This leads to the high lever error condition:
Failed to connect to card: Card command failed
which is slightly misleading, because it certainly connected to the card, it just wasn't able to get any data from it using a GET DATA command. This isn't that strange because it didn't first select any applet and GET DATA (with INS-truction CA) is not likely to be present in the root folder / applet.
TL;DR your connection is fine, now start programming it by issuing GlobalPlatform card manager commands to it. If possible use a different tool or get opensc tools to skip the identification phase / initial commands to it.
IsoApplet and OpenPGP are two different world. For OpenPGP support, look at either SmartPGP by ANSSI-FR on github or ykneo-openpgp (also on Github).
For signatures, you also do not need pkcs15-crypt but should work via PKCS#11 library instead.
For this specific reason - the card being matched as epass, disable the epass driver in opensc.conf.

CCID IccPowerOn Status 00h and Error 80h

I send PowerOn CCID command on card insertion to receive ATR. But instead I always get this error:
PC_to_RDR_IccPowerOn (00h Automatic):
bStatus: 0x0
bError: 0x80
Error 80h according to CCID spec "Reserved for future use".
But same code working correctly with other CCID device I have and this device works with other apps. So how I can find what I'm doing wrong?
I have tried different voltages 3v,5v, 1.8v, but for all of them I get exactly same error.
Even when this happens I get correct ATR. So then I'm trying to send APDU (select non existing file to warm up connection) and then I get:
Slot Status: 40h "An ICC is present and inactive (not activated or
shut down by hardware error)"
So what does it mean "inactive" What I should do?
CCID device descriptor:
CCID Device Descriptor:
bcdCCID: 0110
5V Support true
3V Support true
1.8V Support true
dwDefaultClock: 3.75 MHz
dwMaximumClock: 7.5 MHz
dwDataRate: 10080 bps
dwMaxDataRate: 10080 bps
T0 Support true
T1 Support true
dwFeatures * 0x4c4b400
* Automatic IFSD exchange as first exchange
* Short and Extended APDU exchange level support
dwMaxCCIDMessageLength 271 bytes
wLcdLayout 0000
bMaxCCIDBusySlots 01

A20 OLinuXino-Micro 4GB from Olimex - understanding GPIOs

i am using a A20 OLinuXino Micro 4GB from Olimex with Debian on SD Card.
I want to use the GPIOs and have some short question about the configuration of the GPIOs. The GPIO-1 connector on the board has pins numbered from 1 to 39. In the manual I have entries like that:
Pin # | Signal name | Processor pin
23 | PG9 | C19
...
39 | LRADC1 | AB22
In the fex file, I find this:
[gpio_para]
gpio_used = 1
gpio_num = 64
...
gpio_pin_10 = port:PG09<0><default><default><default>
How is defined that the processor pin C19 is routed to port PG9?
And port means exactly what?
How is defined that the port PG9 is routed to pin23 of the connector?
Can the gpio_pin_10 designation be chosen arbitrarily?
At the end I would like to use the LRADC1, to sample a signal, but the fex file doesn't have any LRADC1 entry. Why is that?
Maybe somebody could answer may questions in 2 or 3 sentences so it makes sense to the rest of what I read. Thanks!
Please take a look at A20-OLinuXino-MICRO schematics. You can find wiring:
PG09 - C19
PG10 - D18
PG11 - C18
(...)
In mentioned schematics is also section GPIO EXTENSION in which you can find which A20 SoC pin is assigned to which GPIO:
PG09 - 23 GPIO-1
PG10 - 25 GPIO-1
According to Wikipedia:
A GPIO port is a group of GPIO pins (typically 8 GPIO pins) arranged in a group and controlled as a group.
Mapping between physical pin and pin exposed through fex file to operating system is arbitrary. Of course to get correct results you have to assign GPIO ping not. I don't think that fex compiler check anything other then syntax.
In case LRADC0 (again schematics) it us used for buttons (vol +/-, menu, search, ...) and LRADC1 is exposed through GPIO-1 pin 39.

Addressing ECUs directly using ELM 327 dongle and ISO 9141

I have a VW Golf 4, which is quite old and talks KWP 2000 (ISO 9141) on its CAN bus. I use a dongle powered by ELM 327, connected to the OBD-2 port of the car.
I am trying to send messages individually to each ECU. I tried to change the header of the messages:
AT SH 48 XX F1 (I hoped XX would be the ECU ID; 48 is the flag for "use physical addressing"). Any command I issue (e.g. tried 3E for "tester present") returns NO DATA (I disabled automatic timeouts and set the timeout to maximum value).
Is there a way to send messages directly to the ECU? I am not interested in the set of data provided via OBD-2, neither do I want to re-flash the ECUs. At the moment I just try to find out which ECUs are available on the bus.
Thanks!
VW works on Transport Protocol TP 2.0, hence you need to initialize with 0x200 header.
https://jazdw.net/tp20
See above link for more info.

How to find out the wireless authentication mode?

I'm trying to get the authentication mode (WPA/WEP) on all the available AccessPoints via DBUS API(in Linux). NetworkManager API describes a property WPAFLAGS but I don't get anything out of it (I get Null Flag everytime). D-Feet DBUS debugger also doesn't show anything. Am I missing something, or is the API broken?
Looks like you are doing something wrong:
$ dbus-send --print-reply --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/AccessPoint/995 org.freedesktop.DBus.Properties.Get string:'org.freedesktop.NetworkManager.AccessPoint' string:'WpaFlags'
method return sender=:1.1188 -> dest=:1.2189 reply_serial=2
variant uint32 324
$ dbus-send --print-reply --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/AccessPoint/994 org.freedesktop.DBus.Properties.Get string:'org.freedesktop.NetworkManager.AccessPoint' string:'WpaFlags'
method return sender=:1.1188 -> dest=:1.2190 reply_serial=2
variant uint32 332
$ dbus-send --print-reply --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/AccessPoint/991 org.freedesktop.DBus.Properties.Get string:'org.freedesktop.NetworkManager.AccessPoint' string:'WpaFlags'
method return sender=:1.1188 -> dest=:1.2191 reply_serial=2
variant uint32 276
What you posted returns:
dbus-send: Data item "method" is badly formed
I believe question was about:
interface.Get("org.freedesktop.NetworkManager.AccessPoint", "WpaFlags")
and it always returns 0