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

Mon Nov 9 11:13:24 EST 2015

So excited that the packet sniffer/scanner btle_rx can follow BTLE hopping
data channels now!

It follows ~8ms hopping link successfully! (Because the fastest speed of my
btle_tx is about 8ms gap between successive packets).

Currently it only works on a simple case (which is the most cases in real
world) where channel mapping is 0x1FFFFFFFFF (This means all data channel
0~36 will be used for freq hopping). btle_rx is a fast moving target
currently. More for demonstration purpose than full verification for now.
Will release more soon.

New added options:

    -f --freq_hz

This frequency (Hz) will override channel setting (In case someone want to
work on freq other than BTLE. More general purpose).

    -m --access_mask

If a bit is 1 in this mask, corresponding bit in access address will be
taken into packet existing decision (In case someone want a shorter/sparser
unique word to do packet detection. More general purpose).

    -o --hop

This will turn on data channel tracking (frequency hopping) after link
setup information is captured in ADV_CONNECT_REQ packet.

On Sun, Nov 8, 2015 at 12:16 AM, 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20151110/167f0064/attachment.html>