VK6NX wrote:
Manuel wrote:
Yeah, but what if that site is down? Are you guys even think that far?
No sorry, of course not. Go on, fire up and impress us all.
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 wrote:
Manuel wrote:
The concept is called STUN service, connecting double NAT connections.
The concept
currently used in EE Remote has nothing to do with STUN. Closest would be SAML. Was explaned hundred times.
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 wrote:
Manuel wrote:
I'm really stunned about EE's proprietary walled garden approach.
Yeah, this happens. Just sell SunSDR and select the TX of your love.
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 wrote:
Manuel wrote:
ISo there's no outcry or even a discussion.
There are.
I was generally speaking. I hope you know that.
VK6NX wrote:
Manuel wrote:
For now I cannot see a way to connect within an intranet (LAN-VPN-LAN)
That also happens. The root cause of such condition is called "knowledge gap".
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.