Month: April 2023

Setting up a Remote Station – Part 8 networking issues

I’m seeing some strange networking issues. On a couple of occasions, I’ve lost communication to the remote station.

Currently, the remote station is sitting on the bench, and the RUT-951 router is connected to my home LAN via Wi-Fi. This is also the desired final situation.

On one occasion, the Pi and Windows PC lost comms to the Internet, even though I could access them remotely using ssh or Microsoft Remote Desktop respectively. The only interpretation is that the router lost its default route (which is to the home LAN’s gateway). However, running the route command on the router showed the proper routing table. All very odd.

The most likely cause is that I had the router sitting on top of the 12v PSU. I’ve moved it now.

Luckily, one of my reasons for choosing this router now comes to the fore. Being a router designed for remote installation, it has services built in that enable it to recover from some problems:

  • One is a service to ping a defined IP address (in my case 8.8.8.8) and reboot if a pre-determined number of attempts fail to get a response.
  • The second is that you can set the router to reboot on a schedule.

I have now enabled both services, with the router rebooting at 3AM.

Setting up a Remote Station – Part 7 Testing

I’m far along that I am now able to use the station as if it was remote. There is one exception though – I don’t have the relay that will switch the radio on an off. I have a SONOFF 4CHPROR3 WiFi Smart Switch on order. That should arrive today.

Apart from that, the station works.

If I want to use digital modes, I connect to the Windows PC using Remote Desktop and run FT8 etc from there. For voice modes, I run SmartSDR on my local machine and use Flexlink to connect to the remote radio.

I’m going to be away for a while, so I won’t make further progress for a few weeks, but when I return I need to give consideration to antennas and lightning protection.

Setting up a Remote Station – Part 6 Remote Access

In this post I am going to discuss the need for a local Windows PC and considerations for remote access.

Local Windows PC

I allowed for a local Windows PC in the original spec, but I was hoping to not need it. However, after watching Mike, VA3MW’s YouTube video on his remote station, I changed my mind. Mike’s arguments in favour were:

  1. running Ham-related software locally reduces Internet traffic and latency; and,
  2. having everything local opens up the potential for others to access and use the station with minimal trouble

So, I stumped up for a Mini IT8 from Geekom. This is a micro-PB with an Intel i5, 16GB RAM and 512GB SSD. More than enough for my needs. It runs Windows 11 (unfortunately), but I’m gradually getting used to its foibles.

So far I’ve installed:

The PC is logged into my Microsoft account so the OneDrive replicates to my home QTH.

I’ll access the remote PC over Microsoft’s Remote Desktop client – remembering to play audio on the remote server and not back on the home station.

It’s worth noting that I’m only proposing to use the remote installation of SmartSDR for digital modes. For voice modes and CW I’ll use SmartSDR on my home Mac and use FlexLink to access the Remote Station.

Remote Access

Given that I am designing a Remote Station, access to the Remote Station is a major aspect of the design. The primary requirement is for remote access from my home QTH, but I also want access when I am on the road.

Normally, this would be relatively easy to achieve because the RUT951 would be directly connected to the Internet and I could either open ports or set up a VPN gateway.

In my case though, it is hoped that the Remote Station will be connected to the host’s LAN (as it is at home on the bench), in which case there is an additional router/firewall in the path to the Internet. I cannot assume that I have any potential to control this host-LAN router, so I cannot forward ports or use something like UPnP.

So, what I am doing is to have the RUT951 establish a VPN back to my home network. That way:

  1. I don’t need to worry about the public IP address of the remote station; and,
  2. once the VPN is established, I have full access to the remote station’s LAN

My Home LAN already has a OpenVPN gateway to allow me remote access to the LAN when I am on the road. Hopefully, with this arrangement I can VPN into the Home LAN and also get access to the Remote LAN. We’ll have to see what effect this has on audio latency etc.

Implementation

At the Server end

  • The home QTH OpenVPN server is reachable from the Internet.
  • The Home QTH LAN is 172.29.12.0/24
  • The VPN Server’s Home QTH LAN IP is 172.29.12.11
  • The VPN uses 10.8.0.0/24
  • The VPN server uses the following server.conf (relevant content only)
dev tun 
topology subnet 
server 10.8.0.0 255.255.255.0 
push "dhcp-option DNS 172.29.12.1" 
route 10.29.5.0 255.255.255.0 
push "route 172.29.12.0 255.255.255.0"
push "route 0.0.0.0 0.0.0.0" 
client-to-client
  • The Home QTH’s router has a static route to 10.29.5.0/24 using the gateway 172.29.12.11

At the Remote Station

  • The LAN has the address space 10.29.5.0/24
  • The RUT951 is 10.29.5.1
  • Once connected to the VPN, the RUT is also 10.8.0.5

With this config, the remote LAN is reachable from the Home LAN and vice-versa.