The paper looks into the affect of radio frequency (RF) noise on connection based Bluetooth LE communication and provides a mechanism that significantly improves the time taken to send a message in noisy environments. To be clear, beacon-related scenarios rarely use GATT connection based communication and instead use connection-less communication repeatedly broadcasting short packets on 3 advertisement channels (37, 38, and 39). Connection tends to be used only to set up beacon parameters or for more advanced scenarios where a device such as a smartphone connects to the beacon for bidirectional data transfer to get real time data, for example, more timely motion detection.
The authors distinguish their research as experimentally derived as opposed to analytic (just using calculations). They show how the Bluetooth Adaptive Frequency Hopping (AFH) algorithm allows Bluetooth devices to blacklist interfered channels and re-transmit packets on different frequencies until interference is avoided.
The paper shows how the AFH algorithm mitigates the effects of Wi-Fi interference near a Bluetooth master by blacklisting channels. An interesting insight is that the master is unable to detect Wi-Fi interference near the Bluetooth slave and is unable to adapt resulting in UDP messages being significantly delayed.
“Our experiments show that BLE connections are eventually able to successfully transmit all data packets, even under heavy Wi-Fi or Bluetooth interference”
The authors demonstrate that by lowering the connection interval in response to changes in the link quality, an application can reduced the average number of packets delayed from 6.18% to 0.54%.
There’s a useful tool called bettercap that claims to be the “Swiss Army knife for WiFi, Bluetooth Low Energy, wireless HID hijacking and Ethernet networks reconnaissance and MITM attacks”.
While you might want to use it to test Bluetooth LE security, a more interesting use is for debugging Bluetooth LE. If you are scanning for advertising or creating or using GATT, for example with a beacon, it’s sometimes useful to have a separate way of exercising Bluetooth LE.
Bettercap is written in Go and runs on GNU/Linux, BSD, Android, Apple macOS and the Microsoft Windows. However, a bug in Windows and macOS prevents the Bluetooth commands from working. Hence, it’s for Linux or Android only.
Better caps runs in the browser and you can create scripts.
A PWA is one that can be run in the web browser. There’s no need to install anything and it works offline after it has been loaded.
Web Bluetooth allows the browser to see and interact directly with Bluetooth LE devices. This allows such devices to be configured and controlled from the web browser, where the browser is on a smartphone, laptop or desktop that has a Bluetooth LE adapter.
A particularly useful feature of Web Bluetooth Terminal is that it supports GATT Serial Port Profile. This is a standard interface that allows control of a Bluetooth device in much the same way as via UART. This means it’s possible to send strings of commands to configure and control. Some Bluetooth LE devices such as the HM-10 (make sure you get a genuine rather than fake one) include the Serial Port profile. Alternatively, if you are creating your own Bluetooth LE device you might include the GATT Serial Port Profile as part of the firmware.
The Wiki includes information about Bluetooth LE idioms such as advertising, MAC address, Bluetooth name, GATT, transmit power, measured power, range, RSSI, mesh and the new direction finding feature. It also has links to hardware and programming information.
The article talks about using beacons to promote consumer interaction, track customer shopping patterns and offer rewards but stops short of providing some scenarios and explaining some of the technical possibilities.
Imagine approaching a kiosk and it automatically knowing who you are and providing one touch (or zero touch) vending of your favourite drink or snack. You are billed automatically and you accrue loyalty points. For the merchandiser, think about extra things you could do (or know) if you could target your top customers and offer them frictionless service. These things are possible using beacons.
Depending on what you need to do, the beacon can be in the kiosk or (or and) with the user. If it’s with the user it can be a physical beacon or an app advertising as a beacon. Some scenarios need more functionality or security than is provided with just Bluetooth advertising. In these cases, it’s possible to connect to the beacon via Bluetooth GATT to store or view data.
We have a few enquiries asking whether beacons can advertise while they are connected to. Beacons usually just advertise. However, setup via the manufacturer configuration app or in special cases, devices (or apps) fetching beacon values requires a (Bluetooth GATT) connection. During this time, beacons stop advertising. This means that, during this time, other devices, and hence apps, can’t see the beacon and can’t connect.
Beacons are based on standard Systems on a Chip (SoC) provided by one of four manufacturers : Dialog, Nordic, Texas Instruments and NXP. These manufacturers provide standard base software/firmware that is used by the beacon manufacturers. There was a time when the base software didn’t support advertising during connection. More recently, advertising during connection has been become possible but no beacons (we know of) support this yet. Note also that even when beacons do eventually support this, devices (and apps) won’t be able to connect if a connection is already in progress. The advertising will be set as non connectable.
Google has just open sourced firmware that implements Eddystone on Nordic nRF SoC beacons. Their aim is to get wider distribution of Eddystone beacons and also encourage other devices, for example vending machines and remote control toys, beyond just beacons. This open source release is intended for manufacturers rather than end users. However, hobbyists might also use the software to re-program currently available Nordic-based beacons.
So far, take up of the Eddystone Configuration GATT Service by manufacturers has been slow. Only one of our manufacturers, Sensoro, supports the Eddystone Configuration GATT Service and when you use this mode iBeacon and all Sensoro-specific features get turned off. This is the problem for manufacturers. Not many people want Eddystone-only beacons so manufacturing them is currently a low volume specialist edge case for manufacturers. Also, while Google is trying to standardise firmware and configuration, the higher profile beacon providers probably think it’s in their interest to continue with proprietary features that lock users into using those particular features and their particular platforms.
Most of the time, beacons transmit and the receiving software such as apps on iOS and Android or applications on single board computers (SBC) only read the advertising data. There’s no connection to the beacon. However, for programmatic setup of beacon parameters or accessing some sensor data, applications might need to connect via Bluetooth GATT.
There’s a recent article on How to Work Properly With BT LE On Android. It provides some useful pointers such as not performing scanning and GATT connection simultaneously, avoiding auto-connect and not blocking GATT callbacks.
GATT can be flaky on Android. While scanning for advertising data usually works well, we have found that GATT connections fail all the time on about 5% of devices. This is due to poorly implemented OS Bluetooth software. This means beacon manufacturer-supplied configuration apps can’t connect. The only solution is to use a different phone (or the iOS version of the app on iPhone).
Sensoro have very recently changed the way they enable Standard Eddystone. First, an explanation of Standard Eddystone. This is when a beacon supports Google’s Eddystone Configuration GATT Service. Our previous comments, from the time this service was announced, provide more background information. Instead of Standard Eddystone, most beacons, including Sensoro beacons, have their own custom Bluetooth GATT service that can still support Eddystone (URL, TLM and EID).
The Sensoro configuration app used to have an option to convert the beacon to Standard Eddystone. This was a one way process that caused the beacon to no longer able to be managed by the Sensoro configuration app, disabled iBeacon support and Sensoro’s cloud features. Unfortunately, some of our customers didn’t realise they could use Eddystone with the Sensoro GATT service, saw ‘Switch to Eddystone’ and did the change with a loss of many features. We fed this back to Sensoro and they have listened. They have removed the switch in the configuration app. It’s now performed with a separate app and you can also now switch back to the Sensoro GATT service. The Android version of the Switcher app had a few critical bugs that we have also now resolved with Sensoro.
The majority of, scanning-type, apps don’t tend to connect via GATT and only read the advertising data that’s available to anyone. Connection usually only happens when configuring beacons or in advanced scenarios where the apps needs to read sensor or battery data. Some custom platforms’ apps also connect to beacons to perform platform related things such as remote setup, security or other such things specific to the platform.
The availability of a Man-in-the-Middle framework presents a security threat. The likelyhood depends on the scenario. In the case of most beacons, the main GATT connection activity is one-off beacon setup by an administrator. In these cases the beacon communication interception is very unlikely.
The larger problem might be with platforms’ apps that connect to beacons where GATT connections happen regularly via users (platform apps) and not under control of an administrator. The implications of the communications data being able to be eavesdropped obviously depends on what’s being communicated. That being said, most current non-Beacon Man-in-the-Middle (WiFi) attacks usually have financial motivations. It’s difficult to think up beacon attacks that might lead to financial gain for the attackers. Nevertheless, if you work with such a system that regularly connects to beacons via GATT, you might like to think about the consequences of data and metadata (what’s being changed) evesdropping.
A more positive use of BtleJuice might be to discover and reverse engineer Bluetooth GATT Services. As mentioned in a previous article, some of our beacon manufacturers haven’t documented their Bluetooth Service Characteristics. This means that while they are ok for scanning/proximity type applications, you can’t write your own app to, for example, change programatically the UUID, major and minor and must rely on the manufacturer’s configuration app or, in the case of the Sensoro beacon, their SDK. While this of no consequence for the majority of uses, more ambitious scenarios might want directly access the Bluetooth GATT services. BtleJuice provides a new way to reverse engineer those Bluetooth GATT Services.