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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected] >>> > >>> > > 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 < >>> [email protected]> >>> > > > > 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 < >>> [email protected]> >>> > > > > 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 >>> > > > > > > > > [email protected] >>> > > > > > > > > http://nine.pairlist.net/mailman/listinfo/hackrf-dev >>> > > > > > > >>> > > > > > > > _______________________________________________ >>> > > > > > > > HackRF-dev mailing list >>> > > > > > > > [email protected] >>> > > > > > > > http://nine.pairlist.net/mailman/listinfo/hackrf-dev >>> > > > > > > >>> > > > > > > >>> > > > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> >>> > _______________________________________________ >>> > HackRF-dev mailing list >>> > [email protected] >>> > http://nine.pairlist.net/mailman/listinfo/hackrf-dev >>> >>> >> > > _______________________________________________ > HackRF-dev mailing list > [email protected] > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > >
_______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
