Seg fault using latest bladerf #24
Comments
|
I'm seeing a similar problem. Setup: anything over 28 channels gives: |
|
This is caused by a workaround in my code to fix an issue with the 2.5.0 release of libbladeRF. I should have bumped the patch version of that library so that the code in In the meantime, if you're experiencing this issue you can disable the workaround by setting ice9-bluetooth-sniffer/bladerf.c Line 60 in 489d75a |
|
I may be having the same problem. On Ubuntu 22.04.02 I kept getting the error: I also tried reverting to the FPGA version v0.15.0 that I had on a machine from testing in the past where I know it worked. But that didn't help. So I did a "sudo apt-get upgrade -y". Then it worked for exactly one run... After that I tried increasing the channels which gave an error, and when I went back down in terms of number of channels it continued to error out: So I manually installed the 2023.2 release of libbladeRF from source. And while that got rid of the warning, I was still getting the segfaults. This ticket says to set So if I can help debug this new 50% channelizer but related to the segfault bug, LMK. (And as an aside, and reminder for future-me, when I went to rebuild with the bladerf.c change, after installing newer libbladeRF from source, I got an error of I thrashed around a bit but I believe the success path was first removing the apt-installed copy with which I resolved with |
|
@XenoKovah here's what I did to get everything working on a clean install of Ubuntu 22.04. First make sure to remove any bladeRF packages you installed using apt or manually (check for
If the bladeRF starts giving you lip again, I always suggest replugging (and reloading FPGA) to reset state which should clear up the type of errors you were seeing. |
|
The first thing I did was unplug, replug, and re-run The next thing I did was remove the 2023.02 tag branch's code with Checking with GDB says it's crashing at some function pointer usage in bladerf2_load_fpga() as shown below. To confirm this was specific to the master branch, I then re-removed, re-checked out tag 2023.02 and confirmed again that the However, it's reproducible that if I go back to the 2023.02 branch and load the FPGA that way, ice9 is capped at 50%. (Note because it will be relevant to a future question: I can confirm sniff_2400-2432.pcap has a size proportionate to runtime: ) Q1: So you didn't see a segfault with (I went ahead and filed this ticket just in case it's a real bug.) As an alternative approach, when I was in the master branch and getting the segfault what I can do instead of the At this point, it acts like it's working... But in reality the sniff_2400-2432.pcap is not getting updated and is always 24 bytes large regardless of runtime. Q2: When it seemed to be working, did you check that the pcap was getting filled in with valid data? |
|
Update: Tested with the latest master branch after the ticket was fixed, but the behavior is still the same: with the latest, the pcap doesn't get written. Possibly due to that |
|
It's possible (likely) that you aren't seeing any data with your current flags. You can keep using those flags but also add The most basic test you can run is 4 channels around an advertising channel. Try You can also try to run it with the default flags (all 80 channels @ 96 MHz), because that's my usual testing setup: Interestingly I was able to repro the segfault in |
|
I don't think lack of packets is the problem. But just to confirm that, I went and stuck a known advertisement Zephyr-based peripheral on the same box and confirmed it was being seen by bluetoothctl scan on (BDADDR 11:22:33:44:55:66 below, but you can see there are other devices seen as well.) I have confirmed in the past with Sniffle that 11:22:33:44:55:66 is advertising on all 3 channels. Most of the time when I run Once it starts hitting those WARNINGs it spits them out very fast and I just ctrl-c it. However, exactly 1 time in perhaps 10 tests I saw the following before it hit the WARNINGs: And I confirmed that it did lead to a non-24-byte output pcap. Q1: Is that Q2: How can I increase the buffer size that's being complained about in the warning? (Because it's clearly not an option to decrease the channels down from the 4 that's used in that command.) |
|
Misc other thing I noticed. If I change from 4 channels to 8 channels, the channelization stat goes down drastically. I.e. above you can see w/ 4 channels it's ~21-24 Msamp/sec ~600% realtime. If I do 8 the Msamp/sec is capped at 8.0 for some reason... Seems like another separate possible bug? p.s. I think adv channel 38 is 2426MHz so I corrected from the above which I just copied and pasted from the example which was set to 2428 (unless there was some reason to test specifically with 2428?) |
|
Misc other datapoint. The "burst" outputs are saying it saw a packet right? If so, when I do the same above command but up the channels to 80, I see a decent number of bursts, despite not being able to keep up (which I'm still skeptical about on this ubuntu server w/ lots of cores, so I filed #32 to discuss separately), but the pcap size doesn't increase. The pcap is still only 24 bytes after that. And the same basic behavior is seen with the -a flag |
|
OK various aspects of this project are swapping back in. Seeing channelizer hover around 100% is the normal, expected behavior when your CPU is able to keep up with the samples as they're being served from the bladeRF. You can't exceed 100% in this scenario because you'd be receiving samples from the future. You should only ever see it exceed 100% when reading from a file. Which raises the question, why are we seeing that above 200% with Bursts just refer to RF energy observed on a channel, which may be due to BLE, classic BT, Wi-Fi, other narrowband transceivers (nRF24 series like Logitech receivers). Seeing periodic bursts is an indicator that the data is flowing all the way through the signal processing chain correctly. There's still likely some problem with the data as it comes through. If a burst is correctly decoded as a BLE packet, we invoke libbtbb to dump its contents. If you've ever used ubertooth, the output will look similar to that with the full packet contents displayed in the terminal. If you want to follow along at home as I debug this, set For center channel, we actually want to use one of the odd numbered channels so that the DC offset from the SDR lies between two BLE channels. I typically use 2427. With all that said, here's the command I recommend for smoke testing: |
|
Changed base_name to "test" and recompiled and re-ran. Currently with an advertising peripheral plugged in next to it again, I can issue |
|
OK just sanity checking here. Here's my current setup:
In the sniffer I set The lines with Can you run |
Yes to all of those, with A9 instead of A4. I think the I think we can probably close this ticket (since it diverged a bit from the original segfault discussion) and I will open a new one to discuss the fact that it seems to be missing lots of packets though compared to Sniffle's pcap over the same time period. |
I did a quick test between commit 41ef634 and the latest c123d83 commit from bladerf github's page. I install it using the /usr prefix along with lib/x86_64-linux-gnu cmake options.
With commit c123d83 and the all channels option on 22.04 Ubuntu with the bladeRFxA9 there is an immediate segmentation fault after the program loads and attempts to use the bladerf. With the previous commit 41ef634 it runs fine. This is from gdb with the newer libbladerf in place. Thought maybe it would help, dropping back to the older libbladerf for now.
The text was updated successfully, but these errors were encountered: