"I can reproduce this" -- TYPO "I can't reproduce this"
On Mon, Nov 9, 2015 at 7:54 PM, Jiao Xianjun <[email protected]> wrote: > See comments in line. > > On Mon, Nov 9, 2015 at 5:18 PM, Iluta V <[email protected]> wrote: > >> 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) >> >> I can reproduce this. Maybe you can try to step-by-step debug. I use > hackrf release "hackrf-2015.07.2". You can also try this. AND REMEMBER: > CHANGE: > > lib_device->transfer_count to 4 > lib_device->buffer_size to 4096 > > in hackrf driver: hackrf.c. You should do that change to your HACKRF > source code and re-compile, re-install hackrf software. Then build my tools. > <https://github.com/mossmann/hackrf> > > >> >> 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. >> >> This should be due to your linux file system access rights setting. You > may check by yourself. > > >> 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! >> > You should replace packetX with valid description. Maybe you should read > readme carefully. > > >> >> What you think? >> >> Sincerely, >> >> Iluta >> >> On Mon, Nov 9, 2015 at 2:33 AM, Jiao Xianjun <[email protected]> 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 <[email protected]> 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 <[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
