[Hackrf-dev] A BTLE (Bluetooth Low energy) packet sniffer/scanner sender

Iluta V iluta2009 at gmail.com
Mon Nov 9 04:18:05 EST 2015 

Hi, Xianjun,

Thank you for your response and suggestions. Here are command lines both
for RX and TX and outputs. BTLE discovery mode works the best. For othr
commands there are interesting questions. :)

*RX:*

1. *btle_rx -c 37 -g 6 -a 89ABCDEF -k 555555 -v -r*, and also  *btle_rx -c
37 -g 6 -a 89ABCDEF -k 0000acce -v -r*

I tried with different channels, different gains, it gives out seg fault
message: Segmentation fault (core dumped)


2. I got a readable message with just default descriptions in command line,
and I got RX working on my HackRF now:

*btle_rx -c chan -g gain -a access_addr -k crc_init -v -r*

Cmd line input: chan 0, freq 2404MHz, access addr 00000000, crc init 00acce
raw 12 verbose 1 rx 1dB ((null))

406us Pkt1 Ch0 AA:0000acce
Raw:4d0001002093d408e03311503281c0502242028ae4e04858241002c0041c922c0c11b207049405821c08
6487874us Pkt2 Ch0 AA:0000acce
Raw:02918600b0880000491345804580300283800008a8584400005044a00e0c814140102b10008040100014

*TX:*

1. As non root:

* btle_tx packets.txt*
num_repeat 1
num_packet 3

packet 0
channel_number 37
pkt_type ADV_IND
payload_len 17
num_info_bit 192
after crc24
aad6be898e00119992b1ebd7900201050702031802180418a85def
after scramble 216 0
aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
num_phy_bit 216
num_phy_sample 880
space 1000
INFO bit:aad6be898e00119992b1ebd7900201050702031802180418
 PHY bit:aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
IQ_sample_byte.txt
save_phy_sample: fopen failed!
save_phy_sample: fopen failed!
save_phy_sample_for_matlab: fopen failed!
save_phy_sample_for_matlab: fopen failed!

packet 1
channel_number 37
pkt_type CONNECT_REQ
payload_len 34
num_info_bit 328
after crc24
aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa948da02
after scramble 352 0
aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
num_phy_bit 352
num_phy_sample 1424
space 1000
INFO
bit:aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa9
 PHY
bit:aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
IQ_sample_byte.txt
save_phy_sample: fopen failed!
save_phy_sample: fopen failed!
save_phy_sample_for_matlab: fopen failed!
save_phy_sample_for_matlab: fopen failed!

2. As root:

*btle_tx packets.txt*
packet 0
channel_number 37
pkt_type ADV_IND
payload_len 17
num_info_bit 192
after crc24
aad6be898e00119992b1ebd7900201050702031802180418a85def
after scramble 216 0
aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
num_phy_bit 216
num_phy_sample 880
space 1000
INFO bit:aad6be898e00119992b1ebd7900201050702031802180418
 PHY bit:aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
IQ_sample_byte.txt

packet 1
channel_number 37
pkt_type CONNECT_REQ
payload_len 34
num_info_bit 328
after crc24
aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa948da02
after scramble 352 0
aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
num_phy_bit 352
num_phy_sample 1424
space 1000
INFO
bit:aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa9
 PHY
bit:aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
IQ_sample_byte.txt

See the difference of outputs when as non root and as root.

3.  *btle_tx packets_discovery.txt*
num_repeat 40
num_packet 1

packet 0
channel_number 37
pkt_type DISCOVERY
AA 8
0101-0101
0101-0101
D6BE898E 32
0110-1011 0111-1101 1001-0001 0111-0001
0110-1011 0111-1101 1001-0001 0111-0001
ADVA buffer begin from 7
010203040506 48
0110-0000 1010-0000 0010-0000 1100-0000 0100-0000 1000-0000
0110-0000 1010-0000 0010-0000 1100-0000 0100-0000 1000-0000
display buffer begin from 15
CA1308 11950 22.626 113.823 8 232
1100-0010 1000-0010 1000-1100 1100-1100 0000-1100 0001-1100 0000-0100
1000-1100 1000-1100 1001-1100 1010-1100 0000-1100 0000-0100 0100-1100
0100-1100 0111-0100 0110-1100 0100-1100 0110-1100 0000-0100 1000-1100
1000-1100 1100-1100 0111-0100 0001-1100 0100-1100 1100-1100 0000-0100
0001-1100
1100-0010 1000-0010 1000-1100 1100-1100 0000-1100 0001-1100 0000-0100
1000-1100 1000-1100 1001-1100 1010-1100 0000-1100 0000-0100 0100-1100
0100-1100 0111-0100 0110-1100 0100-1100 0110-1100 0000-0100 1000-1100
1000-1100 1100-1100 0111-0100 0001-1100 0100-1100 1100-1100 0000-0100
0001-1100
length and AD_TYPE 16
0111-1000 1001-0000
0111-1000 1001-0000
payload_len 37
num_info_bit 352
num_info_byte 44
before crc24
aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038
aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038
after crc24
aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038314121
aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038314121
after scramble 376 47
aad6be898ecff751a439a464b16b385209a744c8db66d89ae9ab6313ea88b63e16fd1bcd4090da6d5afc89215d1c6d
aad6be898ecff751a439a464b16b385209a744c8db66d89ae9ab6313ea88b63e16fd1bcd4090da6d5afc89215d1c6d
num_phy_bit 376
num_phy_sample 1520
space 200
INFO
bit:aad6be898e42250605040302011e094341313330382031313935302032322e363236203131332e3832332038
 PHY
bit:aad6be898ecff751a439a464b16b385209a744c8db66d89ae9ab6313ea88b63e16fd1bcd4090da6d5afc89215d1c6d
PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
IQ_sample_byte.txt

r0 p0 at 0us
r1 p0 at 299024us
r2 p0 at 298557us
r3 p0 at 300177us
r4 p0 at 298612us
r5 p0 at 298388us
r6 p0 at 298671us
etc....

4.
*btle_tx packet1 packet2 ... packetX ...  r-1*num_repeat -1
num_packet 5

packet 0
Getting channel number failed! It should be 0~39.
failed!

What you think?

Sincerely,

Iluta

On Mon, Nov 9, 2015 at 2:33 AM, Jiao Xianjun <putaoshu at gmail.com> wrote:

> Hi,
>
> Very glad to see my first "customer ". Two suggestions:
> 1. Can you paste me the exact btle_tx parameters/command-line? Let me
> check if this is a bug.
>
> 2. For btle_rx and btle_rx, not recommend you use like 00000000/11111111
> as access address. Because in my program, this sequence acts as a unique
> word/preamble to do packet detection. It needs to be some "random".
>
> On Mon, Nov 9, 2015 at 00:39 Iluta V <iluta2009 at gmail.com> wrote:
>
>> Dear Xianjun,
>>
>> Thank you very much for the great work you did!
>>
>> I already tried out your packet sniffer. Just installed it. Could you
>> please have a look at my output. Did I get the packet 0 and packet 1 the
>> right way, and did packet 2 failed or because of something else.
>>
>> Maybe you could tell why it is so, and what else I could do to improve.
>> Here is the output for BTLE packets:
>>
>> *packet 0*
>> channel_number 37
>> pkt_type ADV_IND
>> payload_len 17
>> num_info_bit 192
>> after crc24
>> aad6be898e00119992b1ebd7900201050702031802180418a85def
>> after scramble 216 0
>> aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
>> num_phy_bit 216
>> num_phy_sample 880
>> space 1000
>> INFO bit:aad6be898e00119992b1ebd7900201050702031802180418
>>  PHY bit:aad6be898e8dc3ce338c4cb1207730144f9474e0e15eedb378c3bc
>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
>> IQ_sample_byte.txt
>>
>> *packet 1*
>> channel_number 37
>> pkt_type CONNECT_REQ
>> payload_len 34
>> num_info_bit 328
>> after crc24
>>
>> aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa948da02
>> after scramble 352 0
>>
>> aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
>> num_phy_bit 352
>> num_phy_sample 1424
>> space 1000
>> INFO
>> bit:aad6be898e05225f96ea3018009992b1ebd7901b0a8560a77b22020f0050000000d007ffffffff1fa9
>>  PHY
>> bit:aad6be898e88f00837d7977eb0eca3a0a341e7e3e9c3890cabbc513cd8ea9808241b3c038e5c0b4ac187731b
>> PHY SMPL: PHY_bit_for_matlab.txt IQ_sample_for_matlab.txt IQ_sample.txt
>> IQ_sample_byte.txt
>>
>> *packet 2*
>> channel_number 9
>> pkt_type LL_DATA
>> get_next_field_bit: Half octet is encountered! num_hex 1
>> X
>> Invalid packet content for specific packet type!
>> failed!
>>
>> Please let me know what you think! Thank you again,
>>
>> Sincerely,
>>
>> Iluta
>>
>>
>> On Sat, Nov 7, 2015 at 6:16 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:
>>
>>> BTLE packet sniffer/scanner/sender. Some updates:
>>> http://sdr-x.github.io/BTLE-SNIFFER/
>>>
>>> Now all BTLE channels (0~39, bothe ADV and DATA channels) are supported.
>>> You can use btle_tx and btle_rx to send or sniff on any BTLE channel.
>>>
>>> Raw mode are now supported on both btle_tx and btle_rx. Under this mode
>>> of btle_rx, after access address is detected, following raw 42 bytes
>>> (without descrambling, parsing) are printed out. By this way, you can do
>>> other experiments or communication between HACKRF boards easily.
>>> Have fun.
>>>
>>>
>>> On Wed, Nov 4, 2015 at 1:27 AM, Jiao Xianjun <putaoshu at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Based on my previously released BTLE packet sender, now I have done a
>>>> initial version of BTLE packet sniffer/scanner (Just like TI's packet
>>>> sniffer). See here: http://sdr-x.github.io/BTLE-SNIFFER/
>>>>
>>>> Regarding the latency/real-time processing, I did some experiments and
>>>> tries, and believe that even implementation via USB (instead of on board
>>>> MCU), we still have chance to follow those "slow" frequency hopping link. I
>>>> did see many BTLE link was setup as hopping interval >15ms/20ms/30ms by
>>>> packet sniffer.
>>>>
>>>> Main efforts are:
>>>> 1. Algorithm optimization for real-time processing, such as fixed
>>>> point, CRC table, scrambling table, etc.
>>>> 2. change lib_device->transfer_count to 4 and lib_device->buffer_size
>>>> to 4096 in hackrf driver: hackrf.c. Original buffer size and buffer count
>>>> is very big so that latency is pretty big. By this modified driver,
>>>> according to my experiment, seems that tx and rx can be done in less than
>>>> 10ms: processing latency is about 3~4ms, and worst case buffer delay is
>>>> around 4ms.
>>>>
>>>> Snapshots of HACKRF BTLE packet sniffer VS TI's packet sniffer under
>>>> fastest flow of continuous/non-gap BTLE packets sequence to demonstrate
>>>> full real-time processing ability. They capture the same amount of packets
>>>> and contents:
>>>>
>>>> http://sdr-x.github.io/media/mine-btle-sniffer2.png
>>>> http://sdr-x.github.io/media/TI3.png
>>>>
>>>> youtube: https://youtu.be/9LDPhOF2yyw
>>>>
>>>> Besides,
>>>> A new packet type "Discovery" is added, which can display any names and
>>>> services via btle_tx to your App like LightBlue. ( I use this packet type
>>>> in the "ADS-B BTLE Air Relay" http://sdr-x.github.io/abar/ to display
>>>> flight information)
>>>>
>>>>
>>>> On Fri, Aug 22, 2014 at 9:07 PM, Michael Ossmann <mike at ossmann.com>
>>>> wrote:
>>>>
>>>>> I agree that some code on the ARM would be required.  Additionally,
>>>>> there are probably ways to improve the tuning and rx/tx switch timing
>>>>> even from the ARM.  We haven't done much to optimize those things.
>>>>> There may be a lot of time that could be saved by speeding up SPI or
>>>>> I2C
>>>>> communication or by eliminating unnecessary commands being issued by
>>>>> the
>>>>> ARM to the other chips.  It may even be possible to parallelize some
>>>>> things that are now done in sequence.
>>>>>
>>>>> Overall, I'm pretty sure that the timing required for LE operation is
>>>>> achievable, but I'm not sure how close our current code is to being
>>>>> fast
>>>>> enough.
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>> On Wed, Aug 06, 2014 at 09:55:13AM +0800, Jiao Xianjun wrote:
>>>>> >
>>>>> > 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
>>>>> > > > > > >
>>>>> > > > > > >
>>>>> > > > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>>
>>>>> > _______________________________________________
>>>>> > 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
>>>
>> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20151109/8973bdff/attachment.html>

More information about the HackRF-dev mailing list