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

Sat Nov 7 11:16:20 EST 2015

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/20151108/3325fb1f/attachment.html>