Time-Difference-of-Arrival using RPi and RTL-SDR

Work has been having some issues with wireless microphones getting interfered with, so thought we would investigate something like this.

This uses Raspberry Pi’s and RTL-SDR’s to cheaply locate rogue transmitters.

Wanting to see how well it works – and if it could help with the issues, I was think about putting it around the stadium and seeing if we can locate the source of some of the interference.

Please check out the following video :

You can download a copy of the ArchLinux ISO from the following location

http://www.panoradio-sdr.de/wp-content/uploads/2019/04/pi_image_tdoa_v2.zip

I am just going to document my setup here for future use or deployment.

Write image to SD card in the usual way, and power up the Pi.
This image has an unknown root password, and I need to get Wifi working, so take out the SD card after booting and edit the following.

This install of Arch Linux does not have wpa_supplicant running, so it’s not as easy it as it on Raspbian – and given the custom build of this I want to ensure I am not changing to much of either kernel modules or the user space environment.

So to change the root password, which is unknown on this build, you will need to perform this to get into ‘single user mode’.

Mount SD card in another computer
Edit the file : 'cmdline.txt'
Add the following after the text rootwait init=/bin/bash
save the file, exit
Reinsert SD card into pi, and power up.

Once the PI has booted, you should see a prompt:

sh-5.0#

This indicates that you are in single user mode, and you should now be able to do the following.

At the command prompt type: 
passwd <enter>
New password: <enter the new root password>
Retype new password: <enter the same password as above>

Once you are back at the sh-5.0# prompt you can power down the Pi, and you will need to reverse what you did, so it no longer boots in Single User Mode.

mount the SD card into another computer and edit the cmdline.txt file and remove the init=/bin/sh after the rootwait

Save the file, and unmount the SD card, and put it back into the Pi and power up again.
This will create your new Root password as what you entered before.

Once you are at the alarmpi login: prompt you should be able to login now as
root
<your root password>

Once you have logged in as root, type

wifi-menu

This will take you into the Wifi-Menu where you will be able to connect it to your wifi if you chose.
Select your WiFi name in the menu, and enter the password.
This should connect you to the wifi network and give you an IP address.

Confirm this by pinging something inside your network, or even if you can outside your network (8.8.8.8) for example.

ping 8.8.8.8

Once you have successfully confirmed you can ping 8.8.8.8 or something inside your network, you will need to make the wifi adaptor come up on boot.
For this you will need to run the following command

systemctl enable netctl-auto@wlan0.service

The Pi is now ready to go.
For safety and double checking, reboot the pi and make sure it boots correctly and comes back up to the login prompt.

Log back in as root, and confirm you can ping internal and external services again.
Once you have confirmed that, log out – either exit, or pressing CTL+D and login with the following username and password

username: alarm
password: alarm

Actually we should start with changing the password of the alarm user – at the command prompt please type

passwd

and change the password to something you will remember, but hard to guess.

Because this image has an authorized_keys entry for the user ‘alarm’ and I don’t trust that at all, please edit the file (with any editor of your choice) and remove the user : stefan@ubuntu – with this in there, he *could* login without a password

cd .ssh
vi authorized_keys
<double press d> and the line should be removed
type : then wq and then press enter.

It should drop you back to the shell prompt.
From here we will create some new SSH keys for this user – to allow the server to connect to it, to start the scripts and to copy the recorded files for processing.

These SSH keys will enable the server to login without the need for a password, once you have created these, you really need to be very careful who you give them to.
Let’s create the ssh keys:

ssh-keygen -o -a 100 -t ed25519

You can press enter for the name of the file, and please do not use ‘passphrases’ you can just press enter for them twice.
Once the key is made, you should have two new files.
id_ed25519 and id_ed25519.pub

However, once you have created the key pairs, you will need to share the .pub file with your server administrator , and they will need to share their .pub with you for the user that is created on the server for this task.

You will need to put each opposite pair’s .pub contents into the ~.ssh/authorized_keys file.
Once the server has the clients’ .pub entered in, and the client has the server’s .pub contents in the authorized_keys file, seamless interaction should now be able to take place.

However, in the first instance, it would be beneficial to ‘ssh’ to the remote party first, so as to approve the ‘host identity’ interactive prompt that happens when you connect to a machine for the first time.

To attempt to make this as deployable as possible, and not have to run with pinholes through routers and firewalls, I am going to make the pi create a reverse SSH tunnel.
That is, get the pi to connect to the master server via SSH and allow a port to come back through that created tunnel to be able to log into the server without the need of any port forwards or vpn’s.

Not ideal, I would prefer a VPN service, but this is a bit more robust.

Log out of ‘alarm’ and log back into root.
Create a script called the following name:

vi /usr/local/bin/ssh.sh

In that file enter the following details

#!/bin/bash
/usr/bin/ssh \
  -o ServerAliveInterval=20 \
  -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes \
  -o StrictHostKeyChecking=no \
  -i /home/alarm/.ssh/id_ed25519 \
  -N -T -R####:localhost:22 rftracker@PUT-YOUR-TUNNEL-SERVER-HOST-HERE

Please see your server administrator on what port number #### to use, this will enable the server to reverse tunnel once this is running – which we will do on boot, but each of these ports need to be unique to the install.

Once that file is created please make it executable by

chmod a+x /usr/local/bin/ssh.sh

Now we need to make is start on system boot.

Enter the following

vi /etc/systemd/system/sshtunnel.service

[Unit]
Description=MyScript

[Service]
ExecStart=/usr/local/bin/ssh.sh

[Install]
WantedBy=multi-user.target

Now we will create a ‘timer’ script to wait 1 minute after power on, and make sure that wlan0 is running before it will start the tunnel..
This is to ensure that all parts of the system are running.

So create the timer service like so

vi /etc/systemd/system/sshtunnel.timer

[Unit]
Description=Runs myscript one minute after boot

[Timer]
# Time to wait after booting before activation
OnBootSec=1min
Unit=sshtunnel.service

[Install]
WantedBy=multi-user.target

Set permissions and executable bits on the two services

chmod 755 /etc/systemd/system/ssh*

Then we need to enable the sshtimer service to run

systemctl enable sshtunnel.timer
systemctl start sshtunnel.timer

Reboot the Pi.
Once you log in as alarm with your new password, you should have the reverse SSH tunnel running and should see something like

ps aux |grep ssh

/usr/bin/ssh -o ServerAliveInterval=20 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i /home/alarm/.ssh/id_ed25519 -N -T -R2021:localhost:22 rftracker@10.30.0.1

If that line is in your process list, then you have a successful SSH tunnel to the server, and the server now can log into , copy and start scripts from this connected host.

I am pretty sure that is all that is needed for now.
More updates and the final test results should be published once we have it up and running and tested.

Just one thing to note, for future ZL1CLH when he comes to try and work out what he did to get this going…
You will need to use 127.0.0.1 as the ‘localhost’ address when connecting to the ‘remote’ Pi’s if you use localhost, you will actually be connecting to the IPv6 address of the SSH server running on the server, and not actually make it over to the pi.
but 127.0.0.1 will use the port re-direction as specified in the reverse tunnel setup earlier.