I’ve been playing recently with the QO-100 high speed modem, its been working well, but one of the smaller issues I’ve been having is that every now and again I get bad packets. I’ve been tweaking all kinds of settings on my SDR Console as per the documentation and while I receive most packets it was still annoying me that I’m getting the few missed ones. My current setup involves using SDR Console with a networked Adalm-Pluto that is sitting on the roof next to my dish.

After re-reading the documentation I found a paragraph about the USB Ethernet Adapter that I’m using could possibly be the issue. Its a USB 3.0 adapter but since the PlutoSDR only supports USB 2.0 the concern is that the adapter doesn’t enumerate properly. I’ve been using this adapter for a while so I was a bit sceptic, but I figured it might be a good experiment to try something else.

Since the PlutoSDR enumerates as an Ethernet/RNDIS gadget when plugged into a pc it is essentially already networked with that pc and I wondered whether we could just port forward outside connections on that PC to the PlutoSDR. In my case I wanted to do this on a Raspberry PI since I already had a Raspberry Pi Zero in my satellite station that controls the PTT and measures temperatures, etc. To test this I removed the USB Ethernet adapter from the setup and plugged the PlutoSDR directly into the Raspberry PI. I don’t have any PlutoSDR drivers or software installed on the Pi, but since the PlutoSDR enumerates as a network gadget I immediately have an extra network device available on my pi.

The basic concept here is to forward PlutoSDR specific traffic coming in on the network port (eth0) to the PlutoSDR (eth1). First we need to know which ports are being used when we connect to the PlutoSDR. On my setup I have the following needs:
- SDR Console for working the Narrowband Transponder on QO-100 (TCP Port 30431)
- I need to be able to access the PlutoSDR via ssh for settings, etc. (TCP Port 22)
- My PlutoSDR runs a custom DATV firmware so I need to be able to access the webserver (TCP Port 80)
- With the custom DATV firmware I need to send a TS stream for DATV transmissions (UDP Port 8282)
That means I have 4 ports I need to forward from the LAN port to the PlutoSDR ethernet adapter. For the port forwarding we will be using Iptables. Iptables is software that allows us to configure the Linux Kernel Firewall. To be able to do port forwarding we first need to enable the port forwarding with the following command:
sudo sysctl -w net.ipv4.ip_forward=1
Now we can start configuring our port forward rules. I sounds daunting but its fairly simple. Lets start with our ssh port forward. Our plutosdr is accessable via ssh on port 22, however our Raspberry PI also has an ssh server listening on port 22. So ideally we want to choose another port for the input. I’ve decided on using port 23. The rule I’m configuring is that I want any connections on the Raspberry PI on port 23 to be forwarded to port 22 on the PlutoSDR. Use the following command to configure this forward rule:
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 23 -j DNAT --to-destination 192.168.2.1:22
eth0 is the LAN port on the raspberry pi, dport is the port we are connecting to and we want it to forward to our PlutoSDR which has the destination of 192.168.2.1:22. Depending on how your PlutoSDR is configured this might be different. To access the PlutoSDR I can now ssh normally but using the Raspberry PI Address and specifying port 23. For example my Raspberry PI ip address is 192.168.0.212 so I use:
ssh root@192.168.0.212 -p 23

Great, so this works perfect 🙂
Lets fill in the next couple of rules needed. We need a rule for the web interface:
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.2.1:80
We also need a rule for any SDR software connections (by default to port 30431):
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 30431 -j DNAT --to-destination 192.168.2.1:30431
And then lastly I need a rule for my UDP TS feed for the DATV transmissions:
sudo iptables -t nat -A PREROUTING -i eth0 -p udp --dport 8282 -j DNAT --to-destination 192.168.2.1:8282
On most SDR software you can just specify the Raspberry PI Addres (in my case 192.168.0.212), but I had to do the following setup to make it work on SDR Console (it usually autodetects, but it didn’t work for this). You can add it manually using the following settings:

SDR console is now working fine for both receive and transmit. For accessing the web interface I can simply use the Raspberry Pi address in my browser:

And then lastly I configured my FreeStreamCoder for the UDP address by simply pointing it to the Raspberry PI ip address as well.

I’ve tested all the options for a day or so and it seems to be working fine, from an operating point of view I’m not seeing any differences. I’ve tested this both on a Raspberry PI 4, but I’m using this on a Raspberry PI Zero with an ethernet hat and that also works great.

Now that we have it all up and running we need to make sure that our new rules stay persistent between reboots. Firstly lets make sure our forwarding is enabled when the Raspberry PI Boots by editing the /etc/sysctl.conf file and uncommenting the net.ipv4.ip_forward=1 line:
sudo nano -w /etc/sysctl.conf

Next up we can save our rules using the iptables-persistent package which you can install as follow:
sudo apt install iptables-persistent
Normally it then asks you to save the current rules to a file that it uses to reconfigure them on reboot. You can yes here:

If you ever change the rules then you can update the iptables-persistent configuration file with the following command:
sudo iptables-save > /etc/iptables/rules.v4
And that covers everything you need to know to use a Raspberry PI to put your PlutoSDR on your network without using a USB-Ethernet Adapter. More testing is required, but it seems to be a good alternative for the USB-Ethernet gadget for getting the PlutoSDR on my network. The other advantage of having the PlutoSDR connected to a Raspberry PI is that I can now also run software on it that will use the PlutoSDR directly. More experimentation around that sometime in the future.
So I guess the big question is whether this fixed my bad packets on reception with the QO-100 HS Modem? Its only been running for a day, but so far no dropped/bad packets. I’ll more feedback after having it run for a while longer, but so far so good 🙂

Until next time!
73, ZR6TG
Great idea and improvement Tom. It will also be less finicky than the adapter as we both saw how fickle it was during our club presentation recently.
73
Gary ZS6YI
Thanks Tom ……👍👍
73 ON1RC
Chris
Will it work on Raspberry Pi 3B?
If so have you got a idiots guide as I have tried and failed.
I have a hate relationship with Raspberry Pi’s but appreciate the need.
73’s
Martin
G8KOE
I have tested it on a pizero and pi4 so fairly certain it should work on a pi3. Where are you getting stuck Martin?
pi@raspberrypi:~ $ ifconfig
eth0: flags=4163 mtu 1500
inet 192.168.1.64 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 2a00:23c5:e980:da01:63fc:bb3e:673:60f4 prefixlen 64 scopeid 0x0
inet6 fe80::9bde:eb1e:c7c5:56c3 prefixlen 64 scopeid 0x20
ether b8:27:eb:0a:fc:45 txqueuelen 1000 (Ethernet)
RX packets 93 bytes 10641 (10.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 134 bytes 22116 (21.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163 mtu 1500
inet6 fe80::cc24:2d4c:472d:fc64 prefixlen 64 scopeid 0x20
ether 00:e0:22:d5:ec:53 txqueuelen 1000 (Ethernet)
RX packets 18 bytes 3123 (3.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11 bytes 2487 (2.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
pi@raspberrypi:~ $
Hi Tom,
This is what I get when Pluto connected.
Looks different to what you get.
Is this still OK.
Martin
I had to add this rule for it to work !!
sudo iptables -t nat -A POSTROUTING -j MASQUERADE
(Testing on Pi 2 Model B and Pi zero 2 W)
73
Joël F1JMJ