SysSec-KAIST / LTESniffer

An Open-source LTE Downlink/Uplink Eavesdropper
GNU Affero General Public License v3.0
1.79k stars 184 forks source link

Single antenna mode (-A 1) for downlink seems to select wrong SDR when UHD/soapy sees multiple devices #72

Open hiviah opened 6 months ago

hiviah commented 6 months ago

When using single antenna mode -A 1, LTESniffer seems to ignore -a id=2 selection. E.g. with any SDR this happens:

sudo ./build/src/LTESniffer -A 1 -W 4 -f 1869900e3 -C -m 0 -a "num_recv_frames=512" -a id=2

Result:

/home/gnuradio/persistent/LTESniffer.gnuradio_3.10_docker/build/srsRAN-src/lib/src/phy/rf/rf_uhd_imp.cc:313: UHD unhandled event code 64

Looks like it selected audio card, not the correct SDR.

When using -A 2 with LimeSDR, you can see it chooses the SDR you put in argument:

sudo ./build/src/LTESniffer -A 2 -W 4 -f 1869900e3 -C -m 0 -a "num_recv_frames=512" -a id=2

Soapy has found device #0: default_input=True, default_output=True, device_id=0, driver=audio, label=default, 
Soapy has found device #1: default_input=False, default_output=False, device_id=1, driver=audio, label=hw:HDA Intel PCH,0, 
Soapy has found device #2: addr=1d50:6108, driver=lime, label=LimeSDR-USB [USB 3.0] 9060B00492D13, media=USB 3.0, module=FX3, name=LimeSDR-USB, serial=0009060B00492D13, 
Selecting Soapy device: 2

Then the sniffing works.

Removing the other devices (sound card) from uhd_list_devices by sudo apt remove soapysdr0.8-module-audio makes the single-antenna mode work as LimeSDR remains as the only device.

git commit: 058e05a310dc602a3a2276d36222607fad274264

hdtuanss commented 6 months ago

Hi, note that only USRP B200/B210s can be used for multiple USRPs for uplink sniffing. LimeSDR is not supported yet. Thanks

hiviah commented 6 months ago

Yes I know only USRP X310 and USRP B200/B210 with GPSDO can sniff uplink officially.

However this is issue is for downlink.

I've looked at the past reported issues and it seems clear that people are likely not aware of the meaning of the error they are receiving, especially the UHD unhandled event code 64 which is combination of soapy+UHD+srsRAN error. It manifests in single antenna mode and/or if wrong device is chosen (or was not chosen despite the ID argument in -a).

I've spent quite lot of time debugging that.

You can add this to FAQ about the part of using "cheaper SDR for downlink":

* Uninstall all soapy modules/packages, until only your single SDR device you want to use is shown with 'uhd_find_devices' - this is especially true for soapy-audio, you really don't want to use your sound card
* In single antenna mode, id parameter is ignored in LTESniffer (this seems like srsRAN bug)

Non-USRP SDRs tested:

* LimeSDR - works in single and double antenna downlink mode, use single antenna mode for best results
* BladeRF 2.0 - works in single and double antenna downlink mode, use single antenna mode for best results, might be tricky to set up correctly via bladeRF-cli
* PlutoSDR - avoid at all costs, it's just pure misery. Even if you manage to get downlink sniffing working, the frames/subframes will have 0% success rate. 
 Requires libiio+soapy for Pluto to be recompiled without avahi, if used in docker.
 Despite having AD963x+FPGA (similar architecture to bladeRF) the USB 2 bottleneck is probably causing this.

This is great project, it's just not easy to get working and I figured it'd be just at least useful to have the errors + woarkounds in issues.

hiviah commented 6 months ago

E.g. for LimeSDR on LNAH antenna for my frequency, this gives me ~0% skipped subframes and fairly good success rate:

    sudo ./build/src/LTESniffer -A 1 -W 4 -f 1869900e3 -C -m 0 -a rxant=LNAH