HL2 IP connectivity over a VPN

[Pez]

Hello all,

I am playing around with VPN’s and the HL2, and I have a question: I want to see if I can get some kind of remote connection happening over my private VPN to the HL2 (Yes I KNOW! I am trying to do something that I know won’t work well, but I want to try it anyway!)

I already have a fully working remote desktop solution in place (Splashtop)– I am only looking at this to see what can and can’t be done with VPN.

I’m not an IP expert, but I know enough to be dangerous! hihi. So my question is: is there some specific protocol that the HL2 uses to multicast/announce/broadcast itself across the LAN?

For example, most control software (SDR Console / SDR++BROWN, etc) can find the IP automatically. Some programs (like SDR++BROWN) don’t even allow you to manually specify the IP address, it finds it automatically. But how? What is this method? I want to see if I can get this to happen over my VPN, with SDR++BROWN (check that software out if you haven't’ already – you can even TX on SSB from your phone!).

Thanks in advance,

73

[Matt Nichols]

Why don't you just statically configure the IP address of the HL2 so you don't have to worry about discovery? Just curious. 

If the HL2 is anything like the Anan 10E or Anan 7000DLE MK II (I haven't assembled mine yet, still waiting on some parts) I've owned, the unit attempts to get IP configuration via DHCP and falls back to APIPA addressing (APIPA (wireshark.org))

[G4ZAL]

Running PowerSDR/Thetis requires a lot of low latency network bandwidth.  It doesn't even work very well on local wifi connectivity.

I use Quisk for a 'lite touch' remote connection to HL2 - works well even on low bandwidth connectivity.

I made a short 'how-to' here...

https://g4zal.blogspot.com/2023/01/quisk-remote-operation.html

With Quisk running on a R-Pi3 at the remote/server end and Quisk control head/client running on a Windows laptop tethered to my cell phone for internet connection, it works fine on SSB.

Nigel

[Matt Nichols]

Pez, I'm guessing software like Thetis, SDR Console, etc. "discovery" works by: if a static IP for network SDR isn't known/set, it look for APIPA IP in local arp table for local ethernet interface. Then send a discovery packet to it (like the one used in HPSDR firmware upgrade tool). 

[Pez]

Hi guys, thanks for the replies.

Matt - some software (like SDR++ Brown won't allow a static IP to be set - it seems to only allow auto discover, I assume by UDP Multicast or similar... This isn't method easily piped via a VPN (apparently). Other software like Thetis allows the static IP to be set, but for whatever reason, it still can't see the HL2 via the VPN either (not even detected as being present). Almost like it wants to see the UDP multicast to "wake up" - then it will lock in the static IP... (Just a guess, I could be wrong).But it wont work regardless. 

G4ZAL - I have good networking equipment here, (Fortinet and Ruckus) and I am having no issues on my WiFi, although I am using Ethernet for these tests anyway. I did setup Quisk via your guide previously (thanks a lot!). It works, but the UI isn't as slick as I would like (I'm used to ELAD and Flex and SDR Console style of UI - I just can't get used to it). Ideally, I would love to see Thetis or SDR Console support remote RX/TX. I am running SDR++Brown SERVER (RX mode only at this stage) via full remote now, and it's very good! With its "Int8" sample type, at 192000 its only using 3Mbit/s bandwidth for perfectly smooth operation on Android (4G network) and on Windows (via any normal internet type you like). It's working very well for me. Even when I bump the sample rate up to 384000 and change the sample type to "Int16", at 13Mbit/s, the remote still works well here. 

Do you know how much low latency bandwidth Thetis needs for comparison? 

73

[Pez]

Thanks Matt - I think it is definitely something like you described. - however setting a static IP doesn't seem to resolve over VPN regardless. I would have expected (worse case) that it would see the HL2, but then fail to start or die quickly after starting. It can't even see the HL2 for me though.

73

[Jim Ancona]

The Metis protocol uses UDP/IP and discovery uses UDP broadcast, which means it only works on a single subnet. Does your VPN support UDP? You might want to check the logs of the program you're using to see if it's finding the VPN network interface and sending a discovery packet to it.

Jim

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/26f43f56-e7df-44cc-85eb-65912975c974n%40googlegroups.com.

[ron.ni...@gmail.com]

If your preferred software is currently in development, and doesn't allow setting an IP address for the HL2, you might want to submit a bug report to the developer.  

The HL2 does not announce itself on a network.  Instead, the HL2 waits for a UDP packet containing a discovery message, and then responds to that by transmitting back a UDP reply to indicate it's existance (including its gateware version number, MAC address, and etc.).  Most Metis software uses UDP broadcasting to blast out discovery UDP packets on the local subnet.  But it doesn't need to be a broadcast UDP packet for the HL2 to respond, a directed UDP packet will also work.  Note that some systems (iPhones?, corporate firewalls, etc.) block apps from UDP broadcasting, so an alternative strategy is to either use a fixed IP for the HL2, or to send send individual UDP packets to IP addresses in the suspected address local range until an HL2 replies.  

73, Ron, n6ywu

[Alan Hopper]

Hi Pez,

there are two issues here, the discovery packet will typically not escape you local network and software really wants to know what the capabilities of the radio are (which the reply to the discovery  package contains).

Because of this the HL2 was updated to respond to discovery requests sent directly to it as well as broadcast packets. I suspect most software now has an option to set an ip address or search range (SparkSDR certainly has), network latency can also be an issue but you can be lucky.

73 Alan M0NNB

[Pez]

Thanks for the input all. Much appreciated. 

Jim - my firewall is Fortinet so its very capable - I would assume the required UDP packets are not passing over the VPN, from everything I have seen so far. I will look deeper into the options (many advanced features are managed via command line, so I will need to do some reading...) 

Ron - FYI, Thetis allows setting of the static IP but it would not appear to work in this way for me (over VPN). 

Alan - Thinking more about this, I assume the "directed packet" that the you mentioned is generated from the software (Thetis in my case).  I have set my HL2 with a static IP, but so far I have had no luck trying this way over my VPN. 
I assume that this is because all UDP broadcast packets of this type are not sent over the VPN (and therefore across different subnets).

I will try a few more things on y VPN as time allows, and see if I can connect. Thanks again everyone for the insight. 

73

[ron.ni...@gmail.com]

Can you ping any IP addresses on the same subnet as your HL2?  And/or ssh into any servers on the same subnet?  If so, it may be that either your computer, VPN, or firewall are blocking broadcast and/or directed UDP packets to or from the HL2.  I test for this kind of problem by co-locating a Raspberry Pi (or other linux server) on the same network switch as the HL2, and seeing if a UDP echo server will return UDP packets.  In one case, I found a problem that was due a firewall setting, but only for UDP packets in one direction.

73,

Ron

n6ywu

[Ron Lewkowicz]

A ssh tunnel for UDP may be another thing to try.  If you have multiple levels of IPTABLES or what some refer to as CGNAT from your ISP ngrok is supposed to be able to get through that.   I have this on my internet. I've looked into ngrok a bit but have not tried a setup.  My internet is still not really fast enough and small data allowance to do much of anything like this.  For remote radio operation I would also have to upgrade to an Advanced amateur license.  My QTH is already pretty remote :)

[Pez]

Firstly, thanks everyone for the assistance so far - both here and the many private emails I have received - it is appreciated!

The summary so far is that this works very well for some people, and not for others. UDP discovery across the VPN seems to be the key problem here, and not the ability for me to see/access the HL2 IP address (which is static and can be pinged). 

@Ron -  "Can you ping any IP addresses on the same subnet as your HL2?  And/or ssh into any servers on the same subnet?  If so, it may be that either your computer, VPN, or firewall are blocking broadcast and/or directed UDP packets to or from the HL2".  

Yes I can, and I can ping the HL2 IP address itself through the VPN (192.168.1.123). Even the Thetis "Firewall Check" is successful. I am good with traditional TCP and port forwarding, but this UDP stuff is a different ballgame. I have access to multiple devices on my home network, not only via VPN, but also with traditional TCP port forwarding. It seems the UPD discovery is not making it across my VPN. I need to look closer at this.  

@ron - A ssh tunnel for UDP may be another thing to try.  If you have multiple levels of IPTABLES or what some refer to as CGNAT from your ISP ngrok is supposed to be able to get through that.  

I also have a Static, Public IP address at home - I'm not behind a CGNat.  FYI - I have multiple other remote radio solutions running with traditional port forwarding across the internet - no VPN, no problems (Remotehams / Icom RS-BA1 / Kenwood ARCP / Win4Icom Suite, etc). I don't need to use the VPN for any of these. 

I think I have 2 options (maybe 2):

1 - go deeper into my VPN configuration and see if there is another way to transport/tunnel the required UDP across the VPN natively. 

2 - I wonder, can I try to do this OUTSIDE of the VPN environment? Given I have a very controlled IP setup here (with no CGnat, a Public Static IP, etc.) can I do this with "traditional" port forwarding?? - Is this possible with UDP Discovery Packets? Do / can they use a defined "port" without some additional middleware to make that happen?  As far as I know, there is no "port to open" when it comes to the UDP discovery packets that I need to wake up the HL2??? So, this might not be possible. I don't really want to use any middleware. 

I wish this could just be as simple as an IP address and a port forward, with my HL2 and Thetis!!! ;)

73

A screenshot of my remote across the VPN side:

[ron.ni...@gmail.com]

I you have a working static IP, but your SDR software is incapable of having that IP configured, and broadcast UDP doesn't get accepted by your VPN, one possibility is to run a proxy outside your VPN that captures the broadcast UDP discovery packet and turns it into a directed UDP discovery message to your known static IP for the HL2.  The HL2 can't tell the difference between a broadcast and directed UDP discovery message, and will respond appropriately.  Just an idea.  It might be easier to recompile your SDR app with a hard-coded fixed IP in place of the non-functional discovery code.  73, Ron, N6YWU

[Carmine Iannace]

I understand your issue and it is a common one. This issue also affects other SDR transceivers such as the FlexRadio 6000 series when used over a VPN. You need to use a bridged VPN rather than a routed VPN.  The vast majority of VPN's are routed meaning they will not pass broadcast packets used to "find" the transceiver on the remote network . In order to pass broadcast IP traffic of data you need a VPN that will bridge the local and remote networks together via an encrypted layer 2 tunnel. There are many ways to do this such as using OpenVPN in TAP mode (bridged) instead of TUN mode (routed) but it is difficult to get running. I would recommend you look into the free and opensource SoftEther VPN (https://www.softether.org/). SoftEther VPN is natively a bridged style VPN that will bond two networks together through a secured, encrypted VPN tunnel. The type of tunnel to be use  is Layer 2 over IPSec (L2TP IPSec). It can run on Windows, a Raspberry Pi or Linux. It work great and is very fast. 

K1VL

[Pez]

Thanks guys,

I have a fairly good grasp on the reasons for the lack of connection over my VPN now, and I am going to study up on the UDP discovery packets, and the options I have available in my Fortinet routers to tunnel this. 

@K1VL, I have used Softether on a Pi in the past, and it was great (for a different application). So I might have another look at this as well. 

73 

[Andy Zwirko]

Pez

  You need to investigate whether your routers support something called layer 2 bridging over VPN.  I've done this in the distant past using OpenWRT routing software running OpenVPN on ASUS hardware.  This allowed me to build a local and remote network where both LAN subnets used the same IP space, like 192.168.1.0/24.  Here is a good article that explains and also visualizes the LAN IP address subnet sharing

https://openvpn.net/vpn-server-resources/site-to-site-layer-2-bridging-using-openvpn-access-server/

It says no longer supported, so I don't know if you can find the older version online and employ it for your issue or it still works but the org won't support you.  This concept of bridging at layer 2 is exactly what's done on WiFi extenders, such that all traffic is mirrored across different boundaries.  I've done it across LAN/WAN, it works and would solve your issue.

Finally note that layer 2 bridging sends ALL traffic that would normal never cross your router/gateway between the two LANs.  If you've ever run WIreshark on a PC and sniffed traffic, you might see lots of broadcast, local, multicast and even non-IP traffic that never gets past your home router.  This type of bridging listens for and forwards it ALL, so expect your WAN bandwidth utilization to go up depending on what other devices exist on each network.

73 & GL

andyz - K1RA

["Christoph v. Wüllen"]

Bottom line first: it is possible to connect to a remote HL2 without any
special VPN software if you can "ping" the HL2, but it needs support for
this in the SDR program. I report on an experiment with piHSPDR.

The question came up here "Why can't I connect to my remote HL2 if I
can ping it". The answer is that there is no technical reason why
you can't, but the "discovery process" needs an additional try with
a fixed IP address.

a) The standard way of "discovering" radios is to send a broadcast UDP
backet to port 1024 on each adapter (including virtual adapters such
as VPN) in the system, then it waits for a response. Broadcast
packets have to "target address" and thus are not routed, so you do not
get and answer if there is no radio on a subnet directly attached to
the computer.

b) Connecting to a remote HL2 is possible this way through VPN, if
VPN "bridges" two subnets into a single logical one. This is normally
not the case case for standard VPN setups

c) Technically, you do not need VPN at all, you can simply connect to
a distant radio (see below), but then everybode else can also connect.
So VPN is required solely for security reasons.

d) You can send an "UDP packet with target address" to any HL2 in the
world, and will get a response, if you know the IP address of that
remot HL2, you simply have to do it. Then you can connect the
same way and operate. I have built this into piHPSDR: after sending
the broadcast packets (see a) I send an additional UDP discovery
packet to the IP address specified in the "IP addr" field in the
discovery screen. You get a valid response (see first screen shot)
and you can tell this is from a targeted UDP discovery because
it states "UDP" where you usually find the name of an internet
adapter.

e) My setup was: HL2 connected to an internet router, Computer connected
to the internet via the Campus WiFi of our university. After discovery,
I get

[Alan Hopper]

Hi Christoph,

This is exactly what SparkSDR does (with the option of a range of ip addresses) and a number of people use it successfully over vpn. I also send a discovery direct to ip after a broadcast discovery has worked, this 'warms up' the routing( that can be slow on macs) and prevents timeouts on starting the radio. The HL2 gateware was tweaked a long time ago to allow this, the original Hermes gateware would not respond to non broadcast discovery.

73 Alan M0NNB

[Pez]

This is fantastic information. Thank you Christoph! I have has some success. 

I just did the following:

1 - On my LAN where the HL2 is installed, I opened/forwarded UDP port 1024 to my HL2 IP address
2 - With no VPN at a remote site, I tried to connect over the internet with Thetis, using my public static IP address  - no connection.

3 - I downloaded SparkSDR, and again with no VPN at a remote site I entered my remote public static IP address, and I was able to connect and control my HL2 over the internet straight away! Awesome! (But obviously not secure at all).

So, is there anything wrong with a general feature request to the Thetis developers, to add the same method of directed UDP wakeup (as per SparkSDR and piHPSDR)? Or is forwarding port 1024 UDP a big problem, and the reason this isn't done already? 

If this idea is acceptable, could we just add some app-level username and password credentials to secure things? 

73

[LA8OGA]

Hi

I was directed to this thread by a another radio-amateur, perhaps I can be of help.
Using UDP over a VPN works fine if the VPN is a bridged VPN. We have used e.g. the sunSDR with pretty good results both for CW and FT8 remote operations.

One important thing to remember for a bridged VPN is:
   The client network address must be different than the remote network address. E.g.:

   If the client is connected to a private network with 192.168.1.x then the remote end can not have the same range..The best thing is to setup the remote end with a non-standard address range not likely used by any commercial internet routers. As an example: On remote end, use e.g. 10.98.99.0/255.255.255.0

I did a setup of a RPI OpenVPN server for my ham friend. The description for this is located here: https://github.com/linuxdevel/openvpn

Hope this helps?

73 
LA8OGA

[Steve Haynal]

Hi Pez and LA8OGA,

Thanks for your help with VPN. Just for your information, I once connected t a HL2 in Ukraine via VPN and it worked well:

https://groups.google.com/g/hermes-lite/c/iWQw-ZdM3n4/m/Oue-91PoAAAJ

I think the person who setup that VPN still monitors this list and may provide more details. You can search for VPN on the web interface:

https://groups.google.com/g/hermes-lite

73,

Steve

kf7o

[Arne Brune Olsen]

Hi Steve

Unfortunately I don't have a HL2 myself to test it out. But Rune, la7tha has. And I have a bridged VPN connection, based on OpenVPN to his network.

Rune is able to use the HL-2 when he is directly connected to his home network. But from remote, using layer-2 bridge VPN its not working.

I have now done some tests as follows.

- Installed the Thetis SW version 2.9.0.8 on my local windows 10 machine. This Thetis version seems to support HL-2 according to: Releases · mi0bot/OpenHPSDR-Thetis · GitHub

- Connected to la7tha's network. Where the HL2 has address 192.168.1.100, while my machine gets address 192.168.1.233 when connected with VPN.

- Tried to connect to la7tha's HL-2 device. But I get this error in Thetis:

Ok, then I configured a remote tcpdump session over ssh with tcpdump running on the VPN server and wireshark locally on my windows machine. To trace what is happening on the network of the VPN server (Raspberry PI).

What I see there is that my windows machine is first sending one udp packet, to which it gets no response. (Perhaps auto protocol detection). And then right after it sends another UDP packet where the HL-2 actually responds:

The payload for these udp messages is listed below, unfortunately I have not studied the protocol (yet) and currently Im not able to "read it":

msg 1 from my windows 10 to HL-2:

msg 2 from my windows 10 to HL-2:

And then the response from HL-2:

I have not yet identified any other network traffic from the HL-2 to Thetis or from Thetis to HL-2.

Perhaps you are able to see something from the HL-2 response above what could be wrong?

Best regards/73

Arne, la8oga

--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/tEwuHCxwHIw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/1f738fc3-4e05-4e20-a3b7-4e032ac6bbf4n%40googlegroups.com.

[Carmine Iannace]

Arne,

Are you sure OpenVPN is in bridged mode rather than routed mode? To check bridge vs routed mode the OpenVPN configuration file should indicate something such as dev tap0 and not dev tun0 

Carmine

[LA8OGA]

Hi Carmine

I tried to answer on email, doesn't seem that the reply ended up here. 
Yes I am sure it is in bridged mode, see the link I posted earlier about the vpn setup: https://github.com/linuxdevel/openvpn

Arne

[wj.sz...@gmail.com]

Hi
 It would be nice if Thetis could also work through OpenVPN. Perhaps Reid has some ideas for modification or remedy. The authors of Spark SDR, Console V3, and Quisk could possibly provide technical support on how they solved the information exchange between HL2 hardware and their software, as their programs work perfectly with the same OpenVPN configuration.
73, Joe  

[Pez]

Hi everyone, 

A lot has happened, and a lot has been learned since I originally posted this question. I am not an IP expert in any way, I have lots more to learn but I now have this working well in most software other than Thetis (because of how it is currently performing it's "Directed UDP" calls).  As a summary:

• The HL2 will accept both Broadcast UDP and Directed UDP packets on UDP Port 1024
• For remoting, we can work with "Directed UDP" using basic WAN port forwarding and NAT rules in a router, or over a basic VPN. "UDP Broadcast" on the other hand, is a can of worms and is not easily passed over remote or WAN connections (and really shouldn't ever be - so let's just focus on Directed UDP!) 
• If the SDR software (of any type) can do the following 2 things, then we can generally connect to remote HL2's over WAN, or a VPN, assuming the internet connection bandwidth is good and stable enough, and the basic port forwarding/NAT is configured on the router that is connected to the HL2(s):

The software needs to: 

1) Be able to define a static IP address where the HL2 resides to send the Directed UDP packets (a LAN IP address or a remote WAN IP address will work). Note - Thetis allows this now but it doesn't currently work in a way that allows this to occur over WAN, or VPN easily. Reid has looked at this issue briefly. 
2) If the software can then also provide multiple ports (not just 1024) that can be assigned for the Directed UDP addresses specified in 'point 1)' above, then we can access multiple HL2's on a single remote LAN network. (SDR Console is able to do this now - it's great!)

Of course, there is really no security in opening up ports to the HL2 with no password protection, however this is not a great concern for many of us and there are some situations when this can be just fine. Also, if security is a concern to you, just run this all over a VPN instead. The same principles of Directed UDP will still work :) 

The biggest take-away for me so far has been the incredible advice and support received from many people in the HL2 groups. Developers and IP experts have provided great information. I was also told by a few people that this was all impossible - well I am very glad I stuck to my guns because I now have 2 x HL2's working remotely, and it's been a heap of fun! :)

My wishlist for the future would be:

• A basic username/password system added into the HL2 gateware so that the SDR software programs could implement some basic security on the connection to a remote HL2.
• The ability to set the HL2 to listen for Directed UDP packets on any other user specified port (other than just 1024).
• Directed UDP or TCP used and promoted over UDP broadcast for IP radios like this (it's just a pain to work with, IMO but I also understand the benefits at times). 
• More support for IP remoting in both software and hardware in the future as a key objective. 
• Development of some "thin client" solutions for remoting the HL2.

I have nothing but the greatest respect for everyone involved in the HL2 hardware and software community. I am not an IP expert and maybe some will be shaking their heads at the technical problems with some of my comments (sorry about that!). However I have things working well now, and I am very appreciative of the progress and small changes being made by some developers to help remoting become a little easier for everyone. 

73

[ron.ni...@gmail.com]

My "thin client" partial solution to some of the remote connection issues is hl2_tcp (source code on GitHub), a UDP-to-TCP transcoding utility that I run on a colocated Raspberry Pi.  Since the Pi inserted in the network path and running, I can do HL2 discovery and firewall security management via shell commands over ssh.  73, Ron, n6ywu

[Steve Haynal]

Hi All,

Along the lines of Ron's hl2_tcp idea, for some of these situations it may be best to use two inexpensive SBCs at either end. One for standard software to connect via UDP and possibly convert to TCP. And the other for the HL2 to connect to which can reorder UDP packets or convert the TCP back to UDP. This may be cheaper and easier than trying to do anything in the FPGA. Here is a $20 SBC with ethernet (100M is okay for most users) and wifi. There are many other SBCs.

https://wiki.radxa.com/RockpiS/hardware/rockpiS

73,

Steve

kf7o

[Wojtek J. Sz.]

Hi All,

     Thank you, Steve, Pez and Ron, for your responses.

Could you please provide more detailed clarification and explanation regarding the issue of Thetis not communicating with HL2 through VPN? In what ways do Quisk, Spark, and Console V3 differ from Thetis, that they operate seamlessly through VPN while Thetis (and PowerSDR) do not function?

 My premise and proposal do not involve making any changes to FPGA. I have assumed that since Spark, Quisk, and Console software operate successfully, they possess a certain element which Thetis lacks. This leads me to inquire whether Reid, who consistently modifies Thetis for Hermes Lite users, could also introduce additional alterations to the communication methodology between Thetis and HL2, Thereby enabling it to be detected and connected similarly to the methods employed by the aforementioned three software. I speculate that having the authors of these softwares within our discussion group, who have successfully addressed and implemented HL2 communication, it would be considerably easier for Reid to find a solution and integrate changes within Thetis.

Given that three programs are functional while Thetis is not, one could surmise that the issue lies within the SDR software rather than the hardware.

73, Joe

You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/32304404-d719-4afc-88d7-9fb66b32d6c2n%40googlegroups.com.

[Pez]

Hi Joe, 

Yes, this is a Thetis issue and not a HL2 issue. There is seems to be something different occurring with the way Thetis sends Directed UDP, that doesnt work the same as the other software you mentioned. It could be as simple as timing, but TBC. (For example, Thetis might not be waiting long enough to receive the Directed UDP ack from the HL2 when going over a remote connection, and it might be moving on to UDP Broadcast too soon and therefore misses the response from the HL2 - NOTE this is just as an example of what *might* be happening (that is not necessarily the case)..  

Reid is aware of this issue, and he has made some quick changes already, but it did not solve the issue yet. He has said that he might be looking at this part of the code again soon. I think there is another thread here somewhere that talks about this issue. 

73

[Pez]

That is really awesome Ron.  I am going to have a look at hl2_tcp now.... If a Windows transcoder client was (is?) available to talk to the Pi at the HL2 end, this would be perfect for what I am doing (and also for most of the other HL2 users I have spoken to who want remote access as well!) 

73

[Steve Haynal]

Hi Joe,

Thetis/PowerSDR/piHPSDR/linHPSDR (wdsp clients) groups multiple UDP packets before sending. Other software spaces out all UDP packets in time as evenly as possible. This clustering of UDP packets by Thetis makes it more susceptible to jitter on the network. I'm not sure why Thetis does it this way. It may be just historical. 

73,

Steve

kf7o

[Alan Hopper]

Hi All,

Just a note on how spark does discovery, nothing magic, it sends the broadcast discovery on all network adapters and then on the range of fixed IPs if set. It does not wait between sending, if it gets multiple responses from the same radio it ignores the later ones.

73 Alan M0NNB

[wj.sz...@gmail.com]

Hi All, I want to thank everyone for their responses.

The latest modification of Thetis done by Reid is working very well and stably in the Bridged VPN network. Arne LA8OGA has done a great job for HL2 Remote usage (Bridged VPN only requires one Raspberry Pi located in the same location as HL2. Access to HL2 can be achieved from any PC by installing OpenVPN. The configuration involves simply opening/"importing" a pre-prepared file which includes access settings and key file. It's straightforward and quick.)

Previously, all programs such as Quisk, SparkSDR, Console V3, etc., were operational remotely via VPN. Now, thanks to Reid's contribution, Thetis is also working smoothly. 
73, Joe