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

Tue Aug 5 21:55:13 EDT 2014

Hi Ryan,

Thanks a lot for your offering the information. You are mastery on BTLE
protocol! I should learn more.
150us seems too fast for computer, and should consider on-board processing.

BR

Jiao Xianjun

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

> It is possible to hop at such a low rate, but the timing of the
> beginning of each connection event (where the master and slave transmit
> on each channel) has to be very precise. Additionally, a master and
> slave must have a TX-to-RX and RX-to-TX turnaround time of 150 +/- 2 us.
>
> In other words, after a master transmits, it must be able to receive the
> slave's reply within 150 us. A slave must be able to switch from
> receiving the master's packet to transmitting its reply within 150 us.
>
> On Wed, Aug 06, 2014 at 09:30:19AM +0800, Jiao Xianjun wrote:
> > 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 (see attached two .pdf, and search hopping
> > in them). 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.
> > "
> >
> >
> >
> > 
> >
> >
> >
> >
> > 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/a308e3e6/attachment-0001.html>