Hi guys,

after learning, that ExpertSDR2's Client-Server tools are utterly broken (despite the concept/idea behind was charming), I've installed ExpertSDR3 Beta now.

While TCI is really awesome indeed, already working for certain 3rd party applications like JTDX and FLRIG, there seems to be no way to connect ExpertSDR3 remotely to the SunSDR2 without using EE's cloud service (using that "starter" tool). I understand EE's strategy offering an easy solution to their less IT experienced userbase, but what is the point restricting the device manager to the local network segment/broadcast domain ("Discover") and having absolutely no way to enter any other (remote) IP-address?
I don't want to register at or rely on any kind of STUN server for several reasons. Since I operate my own VPN network based on Wireguard®, which is very fast and efficient (UDP-based and multicore capable, the latter in opposite to OpenVPN) and easy to maintain, it's quite obvious to use that solution rather than using the potential in-the-clear protocol through the open internet, NAT-handshaked by a possibly unreliable STUN service provider. Imagine, if such a STUN service by EE is down for whatever reason, or restricted by governmental actions, operators own options to circumvent such a single point of failure are none. It's out of the area of influence.

As long there are no TCI based remote operation solutions (clients, web, apps) supporting CW/PHONE/waterfall yet available, EE should keep open the option to get classic access to the hardware beyond the local network using ExpertSDR3 itself. In my understanding right now it just lacks the option in the device manager to be able to enter a remote IP address leaving the local broadcast domain. I do understand the need for NAT leaving the VPN network (inbound, towards the SunSDR device), since the SunSDR2 does not support network gateways to route traffic back out of its local network.

I haven't looked into the web client yet, since it is bundled for the Windows platform only.

Should I have I missed an option to enter an arbitrary remote IP address or any other way to achieve remote operation, I do apologize.

Thank you for having patience with just another newbie using that awesome gear.

Manuel


PS: To the EE staff. Why are the broken "legacy edition" remote tools are still downloadable, being just a useless trap for newbies, like me?

ExpertSDR2's Client-Server tools are NOT utterly broken AT ALL.

S58WW wrote:
We can debate the used wording, indeed.

But it's simply not working, even locally on the same machine, others seem to be affected as well.
The development has stopped in 2019 and it's considered "unstable" and being "legacy fo a reason" by @Rome.
See: eesdr.com/en/forum-en/remote-control/8232-expertrs-0-6-6-linux-build#24702

Lucky you, that it works for you.

Manuel!
I checked few minutes ago and yes it is still working localy on my network...
I didnt try it on Linux.
Funny it works on V3 (86.8) firmware. I didnt try to transmit. I am lucky I dont need more than that. My shack is in basement. I can not work on Laptop from my living room. One screen is not enough.

Good luck with your remote project.

S58WW wrote:
32-bit Windows version maybe? See: eesdr.com/en/forum-en/remote-control/8232-expertrs-0-6-6-linux-build#15615


Thank you, man.

A thing without knobs is meant to play its full strength in remote operation usage, either the unit sits somewhere in the basement near the antenna cable coming into the house (for less RFI and cable losses) and operators free movement in the whole house (the shack can be everywhere), or it is used from somewhere else for whatever other reason (there are many). You could operate from the hospital still, or even the retirement home (if somebody hosts your physical gear). I embrace that new development, despite whatever some OMs grumble against it. They are the sad guys, when they have to sell their stuff due a new housing situation, which is happening every day.

Possible remote usage and Linux support were my absolute key points to buy a SunSDR.

TCI is a huge step into the right direction. Giving up the (ancient) serial connections was overdue. Good job EE, really!

Yeah, it's not only the hardware, which is well made, it's good software which make the difference nowadays. When did ICOM released the last firmware update for the top seller IC-7300? July 2021? Feature updates? Crazy idea: integrate FT8? Forget about it, standstill. A good starter or backup equipment indeed, but a loss of investment over the typical product life span for the users, if'd you ask me. Generation after generation of Trx models for the flea markets, like in the past decades. SDR is the future, sustainability should be the way of things. But it must work and prove in daily usage. EE's stuff has the potential to be full blown uber-gear, especially software-wise. But others, like the people from Apache Labs, are not sleeping (Thetis is ugly still, an absolute waste of screen space, EE got that right).

For now, using WFVIEW / FLRIG with my ICOM IC-7300 was more fulfilling in remote operation, than my first steps trying to do the same with SunSDR.


Manuel

What will you do in the USA do when our gov makes it illegal to have a VPN?
It's called the restrict Act.
Read about it here:
www.congress.gov/bill/118th-congress/senate-bill/686/text

Manuel!

No 32 bit....

John-KC2QMA wrote:
Do you have your remote radio site in Iran? Or DPR? Cuba? No?

Did you even read that thing yourself? Hint: Check the scope of "foreign adversary" in that proposed bill, section (8) (B).

This might be easier to read: en.wikipedia.org/wiki/RESTRICT_Act

Spoiler:

That proposed bill has nothing to do with you securing a data connection to your remote radio at another site within your own or to another friendly country. On the other hand, section (8) (B) (v) can be a problem indeed, when we see EE's current cloud efforts. While a STUN service is not a biggie, rather have your own network stuff, really.


Manuel

S58WW wrote:
Just to be sure:

I'm talking about having the ExpertRS server software running as a 32-bit executable on Windows (regardless, if Windows itself is 32-bit or 64-bit), as you can run 32-bit applications on 64-bit Windows. The linked post suggests, that only the 32-bit version of ExpertRS for Windows is actually working.

Other than a long drawn out conversion on this topic the best I can tell you is the Language used in this law is so broad it allows the US to decide at will to go after it’s own citizen if they deicide to.
Legal experts have been talking about this for a few weeks.
All I can say is you’ll see soon enough and if I am wrong you can be the first person to tell me “I Told You So”

Got it... I checked .... I have instaled only x64 aps (client and server). At least installers are x64.

S58WW wrote:
Thank you for checking again, much appreciated!

I've returned to ExpertSDR2 and the older firmware, because I was not able to get the TX audio going via RadioSync/Sound card (VAC) for the use with FLDIGI. RX audio was fine. It looks like, that ExpertSDR3 insists using a MIC in DIGU/L mode. You can only manually patch audio line-out in the ExpertSD3 GUI, not the line-in side. The audio routing should be mandated by the DIGU/L mode anyways without touching anything. Whenever I TX, I see my MIC voice in DIGU/L modes. On the other hand, JTDX works perfectly with its pure TCI connection.

Once switched back to ExpertSDR2, FLDIGI was happy again, both ways through VAC.

Another observation was, that the processes of ExpertSDR3 and RadioSync do not really end, when closing their starter scripts. You have to go to the process monitor to kill the still running binaries itself. That's odd.

I will now give ordinary ExpertRS server-client another try, but maybe exposing the whole SunSDR device through VPN is doable.

Manuel

Manuel wrote:
I just tried this approach. It's about forwarding the native SunSDR connection to a VPN endpoint, so not using ExpertRS.

Using Wireshark tapping the SunSDR port at the switch (port mirroring) I first checked how a working connection between a SunSDR and ExpertSDR2 looks like.

Observations:

a) Client side (ExpertSDR2) initiates an UDP session from port 50001 to port 50001 at the SunSDR-device.
b) After a few exchanged packets regarding a) the SunSDR-device itself initiates an UDP session from port 50002 to port 50002 at the client (ExpertSDR2).

To allow the use of VPN, there has to be some advanced packet manipulation to make the SunSDR-device happy.

Situation a) is helped with NAT'ing inbound VPN traffic at the LAN interface of the router, so packets coming from the VPN remote endpoint appear to look like LAN sourced packets.

Situation b) is quite unfortunate, since we cannot just do a) to be done. SunSDR does not allow a gateway configuration (Why is the network stack crippled that way? Just to be a nuisance?). Well, to fix that, we have to take care of outgoing initiated sessions as well. I created a virtual host IP at the LAN router and a rule to forward all (!) inbound connections/sessions (any protocols) on that interface to the VPN remote endpoint address. At the VPN-server in the middle I source-NAT'ed that link to let packets appear coming from the real LAN IP address. LAN-IP addresses are allowed and routed within the VPN links.
Another source-NAT is done at the LAN side VPN endpoint, to enforce connections/sessions from the remote VPN endpoint appear to be created from the virtual LAN IP.

The virtual LAN IP now handles inbound and outbound traffic and the SunSDR-device has no clue, that there's a VPN link behind that IP.

Does it work? Well, this setup works to a point. Wireshark shows similar connections at the LAN switch and the remote ExpertSDR2 opens a connection, but not really. Engaging ExpertSDR2 into the connected status (top left power button) initiates a waterfall (without any signals) and audio, but still shows "Can't start SunSDR2!". After a few seconds or minutes the waterfall dies and ExpertSDR2 goes into disconnected status. If you close the error message ExpertSDR2 disconnects instantly.

Looking at the remote endpoint network stack using 'tcpdump' shows the same connections utilizing UDP ports 50001 and 50002.

So, theoretically it should work, but does not.

Maybe there're some "extras" at the L2 level. Since nothing shows up in Wireshark, ExpertSDR2 might want to see the real MAC of the SunSDR2 in the collision domain or something like that. This might be solved by overwriting the MAC address of the remote VPN interface using the real SunSDR2 MAC value. Uh, that's kinda ugly.

Any other ideas?


Manuel

I am not an expert in this field knowing only enough to get into serious router trouble.

Using Mikrotik router OS you can create EOIP tunnel on top of SSTP or GRE and achieve your goal of end point connectivity via LAN connection. Ethernet bandwidth Base 10 will do and is not critical as 600Kbps will do. Latency is another issue but should not be a problem if RX/TX is less than 100ms. I have not tried Wireguard in this respect.
BK