Does anyone know of an option to use remote control of the radio without having to connect / log in to a third party system? I do not like to "give control" of my devices to others, not even the vendors.
This was probably possible on ESDR2, but I'm looking for an alternative to ESDR3.

The website at cloud.eesdr.com:5450 looks relatively simple, and it should be possible for Expert Electronics to create a version of this that you can download and run on your own server.
Maybe someone from Expert Electronics can also answer this?

Cloud.eesdr.com:5450

Is nothing more than a secure authentication connection handshake

One you have authenticated using the above site that is all that takes place,
After the security is checked and handshake is approved: Your remote connection to wherever your rig is located is a Direct 1:1 connection, cloud.eesdr.com:5450 site is no longer part of the routing. it is just a secure way and handshake of checking you are who you say you are.

If you do not like using that then your choices are one of many Remote connection options such as: TeamViewer, VNC, Splashtop etc. but recall using these methods add another application on each end that will also utilize part of your available bandwidth and you may get less performance in doing so- you will also need to route your input and output audio between the two using these methods as well.

Again the cloud.eesdr.com site is nothing more than an authentication server and once authenticated the connection is direct between the remote and the site where your rig is located

Another way you can try is by extending the local area network using VPN. This allows your remote client to appear on the network where the radio is on as if it was on the same network. This can work well (it is what I'm using) but the current EESDR3 build tends to disconnect if the latency is too high (above 5ms). What you need is to have a VPN client and host.

I don understand this answer from N8SDR:
"Again the cloud.eesdr.com site is nothing more than an authentication server and once authenticated the connection is direct between the remote and the site where your rig is located"

Why is there a delay in the signals even working in same house, same network as the SUN and RPi is. (My client compter is on WiFi right, but still..)

Stig

Replace cloud.eesdr.com:5450 with the ip address for the computer running "starter" as in the server software. i.e 192.168.x.x:5450 or similar

LA3QMA пишет:
No, that doesn't work. No virtual Trx appears, if you do that. I just tried. As for the STUN concept to work both sides 'Starter' and 'Device Manager' need to connect to 'cloud.eesdr.com'. 'Starter' won't stay up, without a successful login, so nothing to connect to there.

It's a mess, if EE decides to allow remote network connections only trough their authentication (actually STUN) service. I don't like that hard 3rd Party dependency, really. What if key figures at EE die in a car crash and EE collapses? Or Mr. Putin closes the Internet for certain parties or applications? 'cloud.eesdr.com' resolves to 95.174.99.52, which is registered for use as a leased line in Russia. All our fancy remote setups will turn into expensive paperweights, if there's no way to do remote operation on ourselves (VPN etc.).

I'm really stunned about EE's proprietary walled garden approach. Most OMs do not see the danger here anyways, as they're not able to comprehend the things behind. So there's no outcry or even a discussion. They're happy, when things work (at present at least) with just a few clicks made, nothing else count. All things are sold as 'feature' and possible side effects are not talked about.

For now I cannot see a way to connect within an intranet (LAN-VPN-LAN), since current 'Expert Remote System' relies on a lonely STUN server sitting in Russia.

I'm quite disappointed, but not ready to give up yet. I'm still trying to extend my local L2 network segment to the remote site using L2 GRETAP via Wireguard VPN. It doesn't work yet, but So far I'm quite close now by using Ubiquity EdgeRouter X (ER-X) boxes with OpenWRT and the needed protocol components. Boths sides are sending, but not receiving.

I just bought a Hermes Lite 2 to finally get a reliable remote operation the fast way. Just around 300 Euros, funny, isn't it? Best part is, that you can throw Apache Lapbs/Anan compatible software at it to have a very good base to start with.

N8SDR пишет:
Yeah, but what if that site is down? Are you guys even think that far?

N8SDR пишет:
The concept is called STUN service, connecting double NAT connections. The idea is good, but shouldn't be solved by only proprietary means. At least open the option to use customers own VPN connection infrastructure. That is no rocket since, as you already had it with ExpertRS.

N8SDR пишет:
You cannot be serious here. If that is the only way out of that single point of failure, you should really go back to the drawing board.

Manuel пишет: No sorry, of course not. Go on, fire up and impress us all.

Manuel пишет: The concept currently used in EE Remote has nothing to do with STUN. Closest would be SAML. Was explaned hundred times.

Manuel пишет: Yeah, this happens. Just sell SunSDR and select the TX of your love.

Manuel пишет: There are.

Manuel пишет: That also happens. The root cause of such condition is called "knowledge gap".

VK6NX пишет:
Make the SAML stuff you do server side public, that would be a start. This will allow us to have alternatives by setting up our own authentication servers.

Then go ahead by allowing connections using classic infrastructure, like you once did with ExpertRS/Client. That might be something embedded in the Server Starter for ERS. I utilize my own VPN servers in a data center. I can change them whenever I want, so no real single entity third party dependency there.

VK6NX пишет:
Sorry, I did nothing with SAML yet. After reading here and there, that there's a handshake with the cloud server and then the endpoints are directly connected thereafter (STUN behaves similar) it was close to think into that direction. But at the end of the day it doesn't matter which exact protocol is used. The single point of failure is a serious matter still.

VK6NX пишет:
Is that the way you handle customers serious concerns? Great.

I have to admit, that 'stunned' was the wrong word. Sometimes I get them wrong, as I'm not a natural English speaker. Sorry about that. It was clear indeed, which way EE goes after the former open source code went closed source. I knew that before buying the unit, but there was silent hope for the best.

Do you ever felt very proud of something you got new and then realized, that it's not usable the way you commonly know and then the people responsible tell you to just go f*** yourself, instead of being informative and of some understanding?

You did an awesome job building that series of quality hardware products and decent GUI and you shouldn't go the same way like F*** S***** being reportedly way too arrogant on customers requests and concerns. That's not the recipe for success in the long run. People do not forget and will go to other (then open source) vendors like A***** L*** etc.

VK6NX пишет:
I was generally speaking. I hope you know that.

VK6NX пишет:
Enlighten me. I have no option in the device manager to enter an arbitrary IP address, which is routable through different local (intra- or VPN) nets. I already understood the need for MAC based device recognition and/or the lack of routing capability. So only L2 bridging over VPN would be the remaining solution, which is a way indeed. But the client/server concept used with ExpertSDR2 was the far better and more efficient strategy, than exposing the gateware via L2 over VPN, which will have the highest bandwidth and latency requirements.

ERS requires cloud based SAML which does not work in closed environments (multi IP segment intranets) IMHO.

Anyways, enabling a mature network stack (having a gateway and L3 routing capability) in the device gateware along dropping the inevitable requirement for MAC based device recognition would be a start to make things much easier. I do not understand, why you take the far more complicated approach.

This was not the first post about my pain getting the remote operation to work. Despair defines the tone used indeed.

If the highest instance of EE is hostile to serious customer concerns, then something is wrong and I did the wrong choice indeed.

I'm sorry about that.

Manuel пишет: I said "it is now SAML like". I said nothing about what it would be in final version. To my knowledge, EE is performing testing and will choose the authernication to their needs. It also might be no authentication at all.

Manuel пишет: I wonder how many times and how many people should tell you "it is not STUN", so the message to sink in?
Let me try
it is not STUN.
it is not STUN.
it is not STUN.
Enough?

STUN main purpose is to join UDP traffic flow sourced from different NATed networks. In EE ERS nothing joins the UDP traffic. ERS Auth performs Auth. Only. End of story. After Auth UDP traffic goes directly from "remote TX" to "remote PC".

Manuel пишет: Honestly, I do not see any serious concers up until now. Not a single.

You want open source? Well, go to Anan, then, there is heaps of open source features you can deploy yourself, just by joining their dev team. Why come here? There was no open source in EE before and never will be. EE always been closed source and will remain (as per their multiple times confirmation on various forums including this one).

If you want to impress this forum to push on EE towards open source, then, first and foremost, bring a proof of any open source project which can compete with ESDR2 and ESDR3. No proof, no talk.

Manuel пишет: No, I do not. Because - with regards of you speaking generally or concrete - there are discussions. Period.

Manuel пишет: Enlighten what?

Tell you that I can connect remote SunSDR tranceiver to remote PC running ESDR3 via either L2 or L3 VPN?
Yes, I can. Many of us can.

Tell you that I can connect remote SunSDR tranceiver to remote PC running ESDR3 via OpenVPN with using EE could (cloud.eesdr.com:5450) for Auth only?
Yes, I can. Many of us can.

Tell you that VPN is not a technology to be used for real time application when latency should stay below 60ms?
No, it not.

Is it still possible to use?
Yes it is.

Till when?
Till EE develop their new view to ERS.

When it would be?
Lesten to Vasily's streams on Youtube.

Enough enlightments?

I guess they just do things their own way. It's a shame the connectivity routes are so limited. FYI Cloud server was down this AM when i attempted to use it.

If I buy a transceiver with an ethernet port, that is controlled by a pc app requiring an ethernet port, I expect to be able to type in the domain or IP address of that transceiver into the app and make a connection over a LAN or a WAN. It should be of no interest to the manufacturer. It's simply none of their business. It's my network. It's up to me how I set it up. The idea that I should let some third party grant me permission to connect to my own equipment (for as long as they happen to be around) is beyond ridiculous, whoever or wherever that third party may be. It may (or may not) only be a 'light touch' during the setup phase. But it only needs a 'light touch' on the off switch of their authentication server, then what?

I totally agree with GW4GTE comments.
I sit here with my SUNSDR2DX switched off for months, not interested and I am on the verge of selling it!
This is after years of 'over promise' and 'un-delivery'. Whist work is undertaken on NON core radio development.
Just get the basics right.
You have the best GUI software but for me I am going to have to sell my radio.
By virtue of the fact that the number of posts on this forum have dropped drastically I guess many people are felling the same.
G8NOF

A couple of days ago, SDRplay released the first version of their new SDRconnect app. It works in local or server mode. This allows you as a client to enter the IP address of your server directly, and connect to it. Wherever it is. No authoritarian intervention.