Radios in other subnets - Why can't SmartSDR for Windows & Maestro be used without auto discovery?

  • 2
  • Question
  • Updated 2 years ago
  • Answered
We've got a bridged VPN/Layer 2 - with multiple Flex Radios in different locations. That setup is running very good for quite some time now. The plan is to move to a routed VPN, as the network grows, bridging ist not the way to go.

With the IPhone client, the remote radio's IP can be specified manually without any UDP broadcast discovery. Agree, that auto discovery is convenient in average home Class-C networks, but I don't like, that it's the only way to contact the radio. 

I'd need Maestro & "SmartSDR for Windows" to be able to be told about static radio IP(s), that are not visible in my broadcast domain. Is there any feature ahead? Maybe some workaround with that filter.txt files? Maybe a hidden knownRadiosList.txt somewhere?

I don't want to start and implement ugly udp-broadcast-relays on our VPN devices, to pack/unpack udp:4992 packages.
Photo of Frank, HB9FXQ

Frank, HB9FXQ

  • 56 Posts
  • 25 Reply Likes

Posted 2 years ago

  • 2
Photo of Steve - N5AC

Steve - N5AC, Employee

  • 1019 Posts
  • 979 Reply Likes
Official Response
​K6OZY is correct.  The discovery protocol was designed, in part, to avoid use in different subnets.  This was done because there ​was no security (authentication, authorization) on the command protocol and we wanted to prevent someone from transmitting, etc. off-subnet without your permission.  I've made a number of jokes about this publicly and they go something like: imagine what a script kiddie, grad student, etc. could do with a 100W transmitter at their command on the Internet.  The major design goal of v2.0 is to eliminate this requirement along with adding security so that full remote use becomes possible.

Backstory: The way the radio works now was very deliberate.  3-4 years ago when we were designing the API, I brought a major concern to our management team about the lack of security.  Along with this concern I provided two options: 1) we could proceed as we are with no security (no authentication, authorization, encryption, etc), but implement some simple steps such as discovery and an off-subnet block in the API to prevent most types of hacking, or 2) we could throw on the brakes and design security into the protocol and then resume work.  

Each solution has benefits and drawbacks.  At the time, the most important consideration was bringing our customers new capabilities as quickly as possible; to pull the FLEX-6000 way ahead of the competition in capabilities before others had a chance to attempt to duplicate what we had done -- to make the competition think twice about venturing down the road we were on until it was too late and they were too far behind.  The major drawback was that it would make customer DIY remote harder.  It was a spirited discussion, but in the end, we opted for the "we'll do that later" model of remote and complete security.  We are somewhat unique compared to any other IoT device in that Internet use is not a core expected functionality from our customer group -- much of the key functionality of the product can be realized with local subnet use.