I am trying to implement a DTLS handshake between two BLE devices. For this, I wanted to use the L2CAP channel of the BLE to communicate with the messages coming from the DTLS. Basically, I want to open a DTLS tunnel with the help of L2CAP from the BLE stack. I am using the mbedTLS library for this. From the documentation of MbedTLS (https://tls.mbed.org/kb/how-to/how-do-i-port-mbed-tls-to-a-new-environment-OS), I understood that I need to set the mbed_tls_ssl_set_bio() function which has the read and write call back functions that communicates with the BLE top layers(L2CAP). I am using the dialog's DA14695 dongles for the implementation. I am not very sure about the read and write call back functions that needs to be written to communicate with the L2CAP channel of the BLE. Somebody experienced with opening a TLS/DTLS tunnel with the BLE top layers can help.
Thanks in advance
Related
Does somebody has experience with implementing the MbedTLS with the BLE devices. I have few questions about setting up the read and write call back functions for the mbedtls_set_bio() functions. I wanted to use the GATT api functions to set up the tunnel with MbedTLS. I am completely new to the mbedTLS and the BLE. I am not quite sure about how to set up these call backs and what exactly they should do. I am using the dialogs DA14695 USB sticks to implement the DTLS handshake between the two BLE devices.
Thanks in advance.
I have been trying to set the limit of pairing the Bluetooth device HC-05(interface by Arduino controller) with my smartphone.
I have tried making this solution work with AT command
AT+INQM=<Param>,<Param2>,<Param3>
Example: AT+INQM=1,9,48\r\n
But instead of converting AT commands using serial.h with embedded C, I am looking for any dedicated library which helps to work this kind solution in using Arduino.
Basically, with the help of Bluetooth device connect to Arduino Nano, I want to send the altimeter sensor data to my smartphone.
During the connection, HC-05 should be responding any one device at a time, if another smartphone tries to pair then the error will be shown.
Please share your advice on this.
Yes there are some libraries in arduino but these are only meant for connection and pairing and low energy connections. We don't have any dedicated library from where we can control the mode of operation of HC05 or any bluetooth module. like bypassing or accessing GAP and GATT services of bluetooth. However there is a way to flash HC-05. But we can only use it for updating the firmware of this device. This github repo is dedicated for this purpose . Hope it helps you
I've been tinkering with the HM-10 board for a few weeks now, trying to push data from phone to module and vice-versa. The ultimate goal was to enable the BLE mode and tweak with the characteristics and GATT profiles. I'm pretty new to this domain so can anyone help me out ?
And is there any way we can interface the HM-10 with the hardware rx-tx channel instead of soft-serial ?
Your question is still not very clear, but i think you mean sending AT-commands over BLE-radio.
To make this possible you have to change the MODE using serial connection.
In standard mode the device can only be configured over the serial connection (pins RXD and TXD) using AT commands.
AT+MODE0: It only accepts AT-commands over the serial connection (RXD/TXD)
until a central device connects to the module.
AT+MODE1: Same as MODE0, once a connection is established,
AT-commands can be sent over BLE and manipulate some PIO pins on
the device.
AT+MODE2: Same as MODE0, once a connection is established,
AT-commands can be sent over BLE.
To test it just send a string to hm-10 as "AT\r\n" and it will respond with OK.
Update:
You cannot change the services and characteristics with AT-commands.
There are a lot of other things you can change,like advertising, setup a beacon and change a lot of settings.
For a full list of AT commands and more see the official data sheet:
http://www.jnhuamao.cn/bluetooth41_en.zip
I'm doing a security analysis project on an IoT device that uses an unencrypted BLE connection (with ATT protocol) and I want to spoof an individual BLE packet with the source address of an already connected device. Is there some tool or API that would allow me to do this easily? I've already tried gatttool and spooftooph but they seem to be connection based and don't allow you to send out single packets with modified fields (as far as I could tell).
You will need some hardware where you can access the radio peripheral directly. What you basically need to do is to find or write a ble sniffer firmware, with the modification that it at a given moment sends a packet on the connection it is currently listening to. But note that the signal strength must be stronger than the original device's signal so it doesn't interfere.
The only open source project I'm aware of is Ubertooth. You will also be able to do this with an nRF52 but then you need to write your own sniffer firmware since Nordic Semiconductor's is closed source.
I can't comment on Emils reply yet, < 50 rep:
Nordic Semis nRF Sniffer v2 needs only the nRF52DK and wireshark to work as a general BLE sniffer. At 40$ it's not that expensive. I know for a fact they will release a new dongle soon that will sell for ~10-15 bucks if you can wait a a month or two.
everywhere I look, if it comes to MQTT messaging, it is all over Ethernet. Unfortunately, I do not have Ethernet wires available.
I am automating my home, wanting to use mqtt as messaging service. My buttons give a signal (like light 'on') to an arduino board running a mqtt client. How do i put out the mqtt message on the serial lines so the transmitted message can be straight forwardly be picked up by an mqtt broker, without using the ethernet cables?
As I was looking for the same answer and didn't find anything to my liking, I decided to write an implementation that enables any Bluetooth, USB or pure serial port communication to send MQTT message. You can find the result here : https://github.com/vortex314/serial2mqtt
It enables any linux machine ( Raspberry Pi 1, Raspi 3 , PC ) to act as a gateway.
It's written in C++ so should be lightweight enough for small devices.
Hope this helps.
Update 27/6 : build folder contains pre-build version for Linux Intel and Raspberry.
I am trying to achieve similar goals for my house automation, although I do have Cat5e in the walls, so could use Ethernet.
Here are some possibilities for using MQTT over serial communication:
Use SLIP between the Arduino and the gateway. The SerialIP client library which implements TCP/IP over serial: http://playground.arduino.cc/Code/SerialIP . Although I have not tested if this works with a MQTT client library. Nick O'Leary's MQTT Client theoretically works with any implementation of the Arduino 'Client' class.
It may be possible to implement MQTT directly over serial, without TCP/IP, although I am not aware of any gateways to do this.
MQTT-SN (a slightly different protocol to MQTT) was designed for sending messages over unreliable transport, and may be better suited to a serial line. If you are interested in publish-only, I wrote a very basic library to send MQTT-SN packets over serial: https://github.com/njh/DangerMinusOne
You could use something like Node-RED on the Linux gateway, talking some other serial protocol (Firmata?) to the Arduino and then converting to MQTT using Node-RED.
I did start looking at MQTT over serial implementations but one of the problems I didn't resolve was how to deal with multiple devices:
Adding lots of serial ports to Linux is complex/expensive (well sort of https://twitter.com/njh/status/570298977310150656)
Reliable serial over longer distances requires extra components for RS-485
MQTT doesn't work well over half-duplex, without an extra layer of software to deal with a master polling slaves for messages
So I am current looking at implementing MQTT-SN for the ENC28j60 ethernet controller...
For SLIP there is also the backwards compatible SlipMux which could easily support MQTT packet types. See also: sending packets over serial comms java
You could build a simple proxy that converts MQTT packets to SlipMux packets on one side and decodes the packets on the other side. The MQTT implementation should not notice anything.