[Hackrf-dev] A BTLE (Bluetooth Low energy)/BT4.0 radio packet sender

Jiao Xianjun putaoshu at gmail.com
Tue Aug 5 21:35:52 EDT 2014


You are correct on that USB latency. I did a quick experiment just now to
test fastest switching speed of my BTLE packet sender via hackrf (Set Space
field to 1, means that I want it be 1ms). It is around 60ms. (See the
snapshot attached, time stamp of the last three packets).

60ms maybe not so bad for real BTLE frequency hopping? I just do a quick
search for this to verify that. Seems that hopping speed requirement is not
so high, and 60ms is OK. Just paste some related words here:

"For a new connection event, master and slave use a new data channel
frequency, which is computed
by using the frequency hopping algorithm. The time between the start of two
consecutive connection
events is specified by the connInterval parameter, which is a multiple of
1.25 ms in the range between
7.5 ms and 4 s. Another important parameter is connSlaveLatency, which
defines the number of
consecutive connection events during which the slave is not required to
listen to the master and thus
can keep the radio turned off. This parameter is an integer between 0 and
499 and should not cause a
supervision timeout. A supervision timeout happens when the time since the
last received packet
exceeds the connSupervisionTimeout parameter, which is in the range between
100 ms and 32 s. The
purpose of this mechanism is to detect the loss of a connection due to
severe interference or the
movement of a device outside the range of its peer.
"

"The frequency retention time in the frequency hopping method shall be 0.4
second or less. For
the radio equipment that uses the frequency hopping method excluding a
combination of the
spread spectrum method and OFDM, the total sum of the frequency retention
time in any frequency
within the time obtained by multiplying the diffusion rate by 0.4 second
shall be 0.4 second or
shorter.
"
Two pdf links:
http://www.google.fi/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0CEUQFjAE&url=http%3A%2F%2Fwww.mdpi.com%2F1424-8220%2F12%2F9%2F11734%2Fpdf&ei=L4DhU6iWFIG7Of7ZgPAL&usg=AFQjCNGNhh5UAbtYpo2YtEt2MgjCbEdj5g&sig2=kZJVDHf2oY31uWFRNtisEQ&bvm=bv.72197243,d.ZWU

https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=237781

(search hopping in them)



​


On Wed, Aug 6, 2014 at 8:54 AM, Mike Ryan <mikeryan at lacklustre.net> wrote:

> I suspect the radio hardware is capable of retuning very quickly, but
> the USB latency is too high for real-time channel hopping. It would be
> necessary to enqueue packets on the HackRF and have the ARM MCU control
> the timing of channel hops.
>
> I didn't mean to sound too negative. Your development is very
> interesting, and I definitely think it could be used as the basis of a
> more robust BLE device emulator.
>
> On Wed, Aug 06, 2014 at 08:50:09AM +0800, Jiao Xianjun wrote:
> > Exactly.
> >
> > What I do is just offering  a tool. Those example is just a simple
> > verification.
> >
> > I think the tool and hackrf do have the full ability, because hackrf can
> > switch from channel to channel very quickly (less than several us? Maybe
> > Ossmann can give some number?).
> >
> > You may define a packet sequence with each packet starting with different
> > channel number as you want, then hackrf will transmit a hopping channel
> > packet sequence.
> >
> >
> >
> > On Wed, Aug 6, 2014 at 12:02 AM, Mike Ryan <mikeryan at lacklustre.net>
> wrote:
> >
> > > Crackle will crack the pairing that is found in *any* PCAP file, it
> just
> > > so happens that Ubertooth is the best tools for producing these.
> > >
> > > The sample packets provided by Jiao Xianjun do not include a pairing
> > > sequence, just the encryption start sequence. Lacking the pairing,
> > > Crackle can't do anything here.
> > >
> > > Also, the sample packets are not part of a legal BLE connection. The
> > > HackRF sits on a single channel (physical channel 9) and sends them
> out.
> > > A real BLE connection hops among the data channels as it transmits,
> only
> > > sending a single packet per channel.
> > >
> > > On Tue, Aug 05, 2014 at 08:26:10AM -0400, Luke Berndt wrote:
> > > > Nicely done! Does anyone know if it would be possible to get CrackLE
> > > running against this? It was designed for UberTooth so I am not sure
> if it
> > > needs some HW.
> > > > https://github.com/mikeryan/crackle/
> > > >
> > > >
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On Aug 5, 2014, at 2:15 AM, Jiao Xianjun <putaoshu at gmail.com>
> wrote:
> > > > >
> > > > > A BTLE (Bluetooth Low energy)/BT4.0 radio packet sender ( build
> based
> > > on hackrf_transfer: https://github.com/mossmann/hackrf  )
> > > > >
> > > > > See project here: https://github.com/JiaoXianjun/   repo BTLE
> > > > >
> > > > > All link layer packet formats are supported. (Chapter 2&3, PartB,
> > > Volume 6, Core_V4.0.pdf :
> > >
> https://www.google.fi/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCAQFjAA&url=https%3A%2F%2Fwww.bluetooth.org%2Fdocman%2Fhandlers%2Fdownloaddoc.ashx%3Fdoc_id%3D229737&ei=ui3gU4GkC-up0AW4q4GwBw&usg=AFQjCNFY1IFeFAAWwimnoaWMsIRZQvPDSw&sig2=wTgMMxNPJ52NHclpsQ4XhQ&bvm=bv.72197243,d.d2k
> > >  )
> > > > >
> > > > > It can be used to transmit arbitrary pre-defined BTLE signal/packet
> > > sequence, such as raw bits to GFSK modulator, iBeacon packet,
> Connection
> > > establishment procedure packet in TI's website:
> > > http://processors.wiki.ti.com/index.php/BLE_sniffer_guide , or any
> other
> > > packets you want. Together with TI's packet sniffer, you will have
> full TX
> > > and RX abilities. See video demo 1 http://youtu.be/Y8ttV5AEb-g
> (outside
> > > China) or video demo 2 http://v.youku.com/v_show/id_XNzUxMDIzNzAw.html
> > > (inside China)
> > > > >
> > > > > ----Build:
> > > > >
> > > > >     cd host
> > > > >     mkdir build
> > > > >     cd build
> > > > >     cmake ../
> > > > >     make
> > > > >     sudo make install  (or not install, just use btle_tx in
> > > hackrf-tools/src)
> > > > >
> > > > > ----Usage method 1:
> > > > >
> > > > >     btle_tx packet1 packet2 ... packetX ...  rN
> > > > >
> > > > > ----Usage method 2:
> > > > >
> > > > >     btle_tx packets.txt
> > > > >
> > > > > In method 2, just those command line parameters (packet1 ... rN) in
> > > method 1 are written/grouped in a .txt file as input of btle_tx tool.
> One
> > > parameter one line. A line start with "#" is regarded as comment. See
> > > packets.txt example in hackrf-tools/src.
> > > > >
> > > > > "packetX" is one string which describes one packet. All packets
> > > compose a packets sequence.
> > > > >
> > > > > "rN" means the sequence will be repeated for N times. If it is not
> > > specified, the sequence will only be sent once.
> > > > >
> > > > > ----Format of packet descriptor "packetX"
> > > > >
> > > > >
> channel_number-packet_type-field-value-field-value-...-Space-value
> > > > >
> > > > > Each descriptor string starts with BTLE channel number (0~39), then
> > > followed by packet_type (RAW/iBeacon/ADV_IND/ADV_DIRECT_IND/etc. See
> all
> > > format examples at the end), then followed by field-value pair which is
> > > packet_type specific, at last there is Space-value pair (optional)
> where
> > > the value specifies how many millisecond will be waited after this
> packet
> > > sent.
> > > > >
> > > > > ----iBeacon example: (iBeacon principle:
> > > http://www.warski.org/blog/2014/01/how-ibeacons-work/ )
> > > > >
> > > > >     ./btle_tx
> > >
> 37-iBeacon-AdvA-010203040506-UUID-B9407F30F5F8466EAFF925556B57FE6D-Major-0008-Minor-0009-TxPower-C5-Space-100
> > >     r100
> > > > >
> > > > > Above command sends iBeacon packet and repeats it 100 times with
> 100ms
> > > time space (If you have "Locate" app in your iPhone/iPad, it will
> detect
> > > the packet and show the iBeacon info.). The packet descriptor string:
> > > > >
> > > > >
> > >
> 37-iBeacon-AdvA-010203040506-UUID-B9407F30F5F8466EAFF925556B57FE6D-Major-0008-Minor-0009-TxPower-C5-Space-100
> > > > >
> > > > > 37 -- channel 37 (one of BTLE Advertising channel 37 38 39)
> > > > >
> > > > > iBeacon -- packet format key word which means iBeacon format.
> > > (Actually it is ADV_IND format in Core_V4.0.pdf)
> > > > >
> > > > > AdvA -- Advertising address (MAC address) which is set as
> 010203040506
> > > (See Core_V4.0.pdf)
> > > > >
> > > > > UUID -- here we specify it as Estimote’s fixed UUID:
> > > B9407F30F5F8466EAFF925556B57FE6D
> > > > >
> > > > > Major -- major number of iBeacon format. (Here it is 0008)
> > > > >
> > > > > Minor -- minor number of iBeacon format. (Here it is 0009)
> > > > >
> > > > > Txpower -- transmit power parameter of iBeacon format (Here it is
> C5)
> > > > >
> > > > > Space -- How many millisecond will be waited after this packet
> sent.
> > > (Here it is 100ms)
> > > > >
> > > > > ----Connection establishment example: (See "Connection
> establishment"
> > > part of http://processors.wiki.ti.com/index.php/BLE_sniffer_guide )
> > > > >
> > > > >     ./btle_tx
> > >
> 37-ADV_IND-TxAdd-0-RxAdd-0-AdvA-90D7EBB19299-AdvData-0201050702031802180418-Space-1000
> > >
> > >
>  37-CONNECT_REQ-TxAdd-0-RxAdd-0-InitA-001830EA965F-AdvA-90D7EBB19299-AA-60850A1B-CRCInit-A77B22-WinSize-02-WinOffset-000F-Interval-0050-Latency-0000-Timeout-07D0-ChM-1FFFFFFFFF-Hop-9-SCA-5-Space-1000
> > >
> > >
>  9-LL_DATA-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-DATA-X-CRCInit-A77B22-Space-1000
> > > > >
> > > > > Above simualtes a Connection establishment procedure between
> device 1
> > > and device 2.
> > > > >
> > > > > The 1st packet -- device 1 sends ADV_IND packet in channel 37.
> > > > >
> > > > > The 2nd packet -- After device 2 (in scanning state) receives the
> ADV
> > > packet from device 1, device 2 sends CONNECT_REQ packet to request
> > > connection setup with device 1. In this request packet, there are
> device 2
> > > MAC address (InitA), target MAC address (device 1 MAC address AdvA),
> Access
> > > address (AA) which will be used by device 1 in following packet
> sending in
> > > data channel, CRC initilization value for following device 1 sending
> > > packet, Hopping channel information (ChM and Hop) for data channel
> used by
> > > device 1, etc.
> > > > >
> > > > > The 3rd packet -- device 1 send an empty Link layer data PDU in
> > > channel 9 (decided by hopping scheme) according to those connection
> request
> > > information received from device 2. (One "X" after field "DATA" means
> there
> > > is no data for this field )
> > > > >
> > > > > Time space between packets are 1s (1000ms). Tune TI's packet
> sniffer
> > > to channel 37, then above establishment procedure will be captured.
> > > > >
> > > > > ----Packet descriptor examples for all formats:
> > > > >
> > > > > RAW packets: (All bits will be sent to GFSK modulator directly)
> > > > >
> > > > >
> > >
> 13-RAW-AAD6BE898E5F134B5D86F2999CC3D7DF5EDF15DEE39AA2E5D0728EB68B0E449B07C547B80EAA8DD257A0E5EACB0B
> > > > >
> > > > > ADVERTISING CHANNEL packets:
> > > > >
> > > > >
> > >
> 37-IBEACON-AdvA-010203040506-UUID-B9407F30F5F8466EAFF925556B57FE6D-Major-0008-Minor-0009-TxPower-C5
> > > > >
> > >
> 37-ADV_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-AdvData-00112233445566778899AABBCCDDEEFF
> > > > >
> > > 37-ADV_DIRECT_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-InitA-0708090A0B0C
> > > > >
> > >
> 37-ADV_NONCONN_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-AdvData-00112233445566778899AABBCCDDEEFF
> > > > >
> > >
> 37-ADV_SCAN_IND-TxAdd-1-RxAdd-0-AdvA-010203040506-AdvData-00112233445566778899AABBCCDDEEFF
> > > > >
> 37-SCAN_REQ-TxAdd-1-RxAdd-0-ScanA-010203040506-AdvA-0708090A0B0C
> > > > >
> > >
> 37-SCAN_RSP-TxAdd-1-RxAdd-0-AdvA-010203040506-ScanRspData-00112233445566778899AABBCCDDEEFF
> > > > >
> > >
> 37-CONNECT_REQ-TxAdd-1-RxAdd-0-InitA-010203040506-AdvA-0708090A0B0C-AA-01020304-CRCInit-050607-WinSize-08-WinOffset-090A-Interval-0B0C-Latency-0D0E-Timeout-0F00-ChM-0102030405-Hop-3-SCA-4
> > > > >
> > > > > DATA CHANNEL packets:
> > > > >
> > > > >
> 9-LL_DATA-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-DATA-X-CRCInit-A77B22
> > > > >
> > >
> 9-LL_CONNECTION_UPDATE_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-WinSize-02-WinOffset-000F-Interval-0050-Latency-0000-Timeout-07D0-Instant-0000-CRCInit-A77B22
> > > > >
> > >
> 9-LL_CHANNEL_MAP_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-ChM-1FFFFFFFFF-Instant-0001-CRCInit-A77B22
> > > > >
> > >
> 9-LL_TERMINATE_IND-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-ErrorCode-00-CRCInit-A77B22
> > > > >
> > >
> 9-LL_ENC_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-Rand-0102030405060708-EDIV-090A-SKDm-0102030405060708-IVm-090A0B0C-CRCInit-A77B22
> > > > >
> > >
> 9-LL_ENC_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-SKDs-0102030405060708-IVs-01020304-CRCInit-A77B22
> > > > >
> > > 9-LL_START_ENC_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
> > > > >
> > > 9-LL_START_ENC_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
> > > > >
> > >
> 9-LL_UNKNOWN_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-UnknownType-01-CRCInit-A77B22
> > > > >
> > >
> 9-LL_FEATURE_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-FeatureSet-0102030405060708-CRCInit-A77B22
> > > > >
> > >
> 9-LL_FEATURE_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-FeatureSet-0102030405060708-CRCInit-A77B22
> > > > >
> > > 9-LL_PAUSE_ENC_REQ-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
> > > > >
> > > 9-LL_PAUSE_ENC_RSP-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-CRCInit-A77B22
> > > > >
> > >
> 9-LL_VERSION_IND-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-VersNr-01-CompId-0203-SubVersNr-0405-CRCInit-A77B22
> > > > >
> > >
> 9-LL_REJECT_IND-AA-60850A1B-LLID-1-NESN-0-SN-0-MD-0-ErrorCode-00-CRCInit-A77B22
> > > > >
> > > > > _______________________________________________
> > > > > HackRF-dev mailing list
> > > > > HackRF-dev at greatscottgadgets.com
> > > > > http://nine.pairlist.net/mailman/listinfo/hackrf-dev
> > >
> > > > _______________________________________________
> > > > HackRF-dev mailing list
> > > > HackRF-dev at greatscottgadgets.com
> > > > http://nine.pairlist.net/mailman/listinfo/hackrf-dev
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nine.pairlist.net/pipermail/hackrf-dev/attachments/20140806/283257ba/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fastest_switching.png
Type: image/png
Size: 115872 bytes
Desc: not available
URL: <http://nine.pairlist.net/pipermail/hackrf-dev/attachments/20140806/283257ba/attachment-0001.png>


More information about the HackRF-dev mailing list