Overflow when using HackRF on wifi_rx.grc

[CodeDragon82]

Overflow when using HackRF source on wifi_rx.grc:

(Same problem with both Soapy HackRF Source and osmocom Source.)

The only thing I've changed in the source input:

Also, I've compared my chart to the one in this issue but I still have the problem: https://github.com/bastibl/gr-ieee802-11/issues/248

Extra info:

• I have tested on a local Ubuntu system, WSL (window's subsystem), and a Kali Linux virtual machine, all with the same result.
• Using the maint-3.10 branch:
  • The maint-3.8 branch doesn't install because there's missing a header file.
• Installed:
  • gr-foo
  • gr-ieee802-11
  • gr-osmocom
  • hackrf (via apt)
  • libhackrf-dev (via apt)

(Please let me know if I'm missing any information that will be helpful.)

[razgino11]

I have encountered the same issue exactly, will update here if i figure it out, keep me updated if you do as well :)

[bastibl]

The HackRF has an uncompensated DC offset, which constantly triggers frame detection, overloading your PC. This was answered several times. Please search for HackRF in the Issues. In short, you somehow have to remove the DC spike through a rather sharp filter. Or 3rd party DC blocker blocks. Maybe the osmocom blocks can also do it.

[razgino11]

@bastibl Thank you! I did look before as well but your explanation helped clear things up,

I came across this amazing article: https://www.rtl-sdr.com/wp-content/uploads/2017/02/Getting-rid-of-that-center-frequency-spike-in-gnuradio.pdf

which recommended this oot block for fixing the problem automaticly: https://github.com/ghostop14/gr-correctiq/tree/master

seems to work great fixing the overflow, still havent figured everything out as far as making the example work but the overflows are gone for me on my hackrf :)

[bastibl]

For normal WLAN, you have to set the bandwidth/sample rate to 20MHz and make sure the signal you are trying to receive is actual 11a/g.

And you have to make sure that you only filter the DC spike but don't disturb adjacent subcarriers. I don't know this block, and was just wondering if you might have filtered out too much :-) There are also links to an adapted flowgraph for the HackRF. IIRC, this used an FFT filter that worked but was not optimized (so maybe it was more narrow than necessary, i.e., might have used more CPU than was actually required).

[razgino11]

@bastibl Thank you very much! setting it to 20 MHz and selecting the correct frequencies worked for me and im getting packets now using hackrf :)

[CodeDragon82]

@bastibl Thank you! I removed the DC spike and I'm getting WiFi frame in Wireshark. I've encountered another problem though. The algorithm seems to only pick up on short frames such as ACKs, CTSs and deauths, and not long frames such as data frames and beacons. Any idea on why this might be?

Info:

• Sampling at 20MHz.
• Using the osmocom source into the DC spike module (correctiq).
• Testing on channel 1, 2.4GHz.

[razgino11]

@CodeDragon82 Checked on my setup and i have the same issue like you again, hadn't noticed i was only getting those packets before My setup:

• Sampling at 20MHz
• 802.11g on channel 7
• using the soapy hackrf source