Will Maestro/SmartSDR 2.0 support connecting to a LAN-connected radio that is not on the same subnet?

  • 4
  • Question
  • Updated 2 years ago
  • Answered
Will Maestro/SmartSDR-2.x permit connection by specified radio IP address, via LAN, that is not necessarily on the same subnet (broadcast domain) as the 6xxx radio?

When I brought this up before, I gathered SmartSDR 1.x is restricted to broadcast-discovery of same-subnet radios because of concerns about Internet abuse. An option was then added to the radio-side to optionally restrict connections to RFC1918 private address space, which seems to me to be a stronger security measure than restricting the client discovery mechanism.

Now that FRS is providing SmartLink for safe supported secure REMOTE authentication, it would solve problems for me and others if we could connect to effectively LOCAL radios which aren't necessarily on our same subnet by specified IP address. I cannot connect to a radio in an adjacent building LAN, or via WiFi, where I am not on the same LAN subnet (broadcast domain) as my Maestro or SmartSDR. The (awesome) IOS client does not have this limitation. I am not asking if I can use SmartLink for a local to local connection and I would prefer NOT to open up a debate about why this matters or how to work around it with extra devices relaying the broadcast discovery packets between LAN segments or bridged VPNs which tunnel broadcast traffic across gateways. If this issue impacts you or you are a developer working on this software, this should be an understandable question. Thanks. -Mark Thomas   KC3DRE
Photo of Mark Thomas

Mark Thomas

  • 52 Posts
  • 16 Reply Likes

Posted 2 years ago

  • 4
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1057 Posts
  • 1097 Reply Likes
Official Response
The idea behind multicast was not entirely for security.  The main purpose was to allow a client to locate the radio without fooling with IP addresses.  We believe pretty strongly that we have customers that are very technical and customers that want to operate their radios without having to become a networking expert.  The latter group is the majority of our customers so our implementations tend to favor this group even though all of our developers are in the first group.  It's not uncommon for us to have the discussion about "yes, that will make most of our customers happy, but there needs to be a way for the nerds (us) to make ti do what we want."  It's a balancing act.

What Tim said is "as it stands today."  We currently have not put direct IP entry into the client.  This doesn't mean we have not considered this nor that we will never do it.  It simply means that there's a lot to do and this is where we are right now.  

Rather than implement IP address entry into the client (which would be a solution), I wonder if there's another adopted protocol that would allow a cross-subnet broadcast.  I've not taken the time to read RFC 5771, for example, which may have some good ideas.  If you know of any non-IP entry solutions, we could likely implement these very quickly and accomplish the same goal (cross-subnet client/radio acquisition) and still keep it simple for customers.

If this doesn't work out, we can discuss options.  The key problem, though, is that we have a long list of things that most every customer could use which we could implement and, in general, these will be higher priority.  Since we do not have unlimited resources, it make it much harder to do things for just a few customers.