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

Mark G Thomas

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

Jim Gilliam

It would seem to me it would be like other servers like power devices with their own server software and the flex would be addressed to the I/P address of the modem and forwarded to a port that is located on the LAN behind the router. That, of course, would imply that port forwarding through the router would be necessary. Or could be addressed with a name if a DNS service is employed.

Mark G Thomas

Please don't take this wrong, but I am not asking how SmartLink works. I am asking about non-SmartLink-facilitated LOCAL connections within the same organization, but on different LAN segments, no public Internet connection involved.

Tim - W4TME

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?

As it stands today, the answer is no.  SmartLink requires access to the Internet by both the radio and the client and they must have different public IP addresses.  Being able to do what you described above is under consideration.

Mark G Thomas

Tim, thank you much for considering this. It is my only frustration to date with this otherwise totally awesome product family.

K1DLM

Tim - I'd like to second the request to be able to enter IP address information manually.  It's not uncommon these days to have multiple subnets on your local LAN.  This has been a thorn in my side for a while now.

John Week

especially since you can already do it in smartsdr for ios.... 

Bill - W9KKN

Just a note, you can sort of do this today if you rebroadcast the discovery packets into the other broadcast domain. Crazy enough, but it seems to work flawlessly.

If you have a Linux machine on both, you can use socat:
Source Broadcast domain (Linux Host IP 192.168.1.10)

socat -u -T1 UDP-LISTEN:4992,broadcast,fork TCP-CONNECT:192.168.2.10:14992

Destination Broadcast domain (Linux Host IP 192.168.2.10)

socat -u -T1 TCP-LISTEN:14992,fork UDP-DATAGRAM:192.168.2.255:4992,broadcast

I haven't tried it, but you could probably also do something like this if you had a system that was multi-homed onto both broadcast domains:

socat -u -T1 UDP-LISTEN:4992,broadcast,fork UDP-DATAGRAM:192.168.2.255:4992

I've been long tempted to write a program that fully fakes the broadcasts and convinces SSDR and friends to just connect to whatever IP I've convinced them is a radio on the local LAN.

Mark G Thomas

I've been using a work-around like this more or less successfully, but it is an awkward and somewhat fragile kludge to make up for intentionally restricted basic networking functionality.

How would you feel cruising around your neighborhood in your fancy and expensive $9k pro racing bicycle, if after you bought it you found out the manufacturer intentionally made it cease to function unless child-training-wheels remained attached at all times, in the name of safety.

Frank, HB9FXQ

I was sure, to get rid of my workaround https://github.com/krippendorf/flex6k-discovery-util-go soon.... Now it looks like FRS decided to promote SmartLink, instead of offering us to simply enter the IP manually on Maestro and Windows. Really not nice. Sorry. I wouldn't be surprised if the manual IP option of the iOs App will be removed with the upcoming release. Private IPs like mentionened in https://community.flexradio.com/flexradio/topics/radios-in-other-subnets-why-cant-smartsdr-for-windows-maestro-be-used-without-auto-discovery would not be possible @FRS???

Mark G Thomas

SmartLink looks great to me. I might even buy it and enjoy it under certain situations, if I am convinced the upgrade won't break at least the current level of networking functionality. I don't think SmartLink is a bad thing at all, maybe it's an awesome thing if it makes secure remote operation easier for users in general. But, it's not the solution to my main use case, and I share Frank's concerns if adding SmartLink might possibly mean new radio-side SmarLink-only lock-downs further impacting LAN access.

For some of us, SmartSDR is restricted in an extremely basic and obvious way. I find it offensive and incredibly frustrating that well-intentioned, but I believe misguided, security concerns are taken to the level where it impedes my basic, and I should add EXTREMELY secure (far more so than using SmartLink over the public Internet), use of the product, on my very own wires and LAN. I keep thinking that surely someone must simply not understand what I ask, and if I use different words or convey it differently, the proverbial light might come on, making it obvious and clear cut. I like my flex. I work around the limitations. But, I might possibly not have bought it if I knew up front that its SmartSDR/Maestro radio client intentionally couldn't do something so elementary as connecting to an IP through an IP gateway on another subnet. I have FIVE subnets in my house, and my WIFI is very intentionally not on the same subnet as the LAN with the radio equipment. I am restricted from implementing something FAR MORE SECURE by a measure intended by FRS to somehow improve security -- that's just broken.

I hold an FCC license which requires I be responsible to secure my station from unauthorized operation. If I were irresponsible, in violation of my license terms, I could hypothetically plug my Flex Radio base running it's current software directly into the public Internet with no firewall in between, and the private-address restriction feature turned off, then anybody on the Internet with some technical knowledge could connect to and make abusive use of the radio using the published API. (I would NEVER do this!) I could as easily set up an unsupervised powered Flex radio on the sidewalk in front of the house, open to abuse my anyone walking by. Whether SmartSDR or Maestro (radio client) will permit specifying a target radio IP or not does not somehow protect someone from abusing a Flex radio base. FRS doesn't send inspectors to my house to make sure I am keeping my radio safe from unauthorized use. They didn't even demand proof of my amateur license to permit my making the purchase. Why not? Because it is not their responsibility to prevent me from doing ****, irresponsible, even dangerous things.

Erik Vallow

I agree with Mark. This is the needless restriction and one that has given me pause when considering purchasing a SmartSDR capable Flex radio. .

73's,

WB3IXY

Steve-N5AC

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.

K1DLM

Steve - Thank you very much for the detailed explanation.  My feedback would be that allowing direct entry of an IP Address into a client seems like a fairly trivial addition from an R&D resource perspective.  This would help greatly when using the radio in a VPN or multi-subnet environment where cross-subnet broadcasts are impossible or impractical.  

Bill - W9KKN

I'd even be fine if it were a command line flag to SSDR. No pretty GUI required; spend as little time on it as possible. I'd actually be a bit surprised if it didn't already exist for the FRS automation testbeds.

Mark G Thomas

On the Maestro, it would take a little more than a command line option, but there is already a screen for Network settings, and under the covers there surely is just an array of discovered radio IPs that we need to push another entry onto. Via some of the workarounds, it is already clear that Maestro and SmartSDR will gladly talk to a radio base on a different subnet, once it's discovery mechanism is tricked with relayed broadcast packets so the radio makes it onto the displayed radio selection list.

Cliff - G4PZK

Forgive me for resurrecting an oldish post but I wasted a little time this afternoon capturing broadcast packets from my Flex 6500 using tcpdump. Please note that this is just preliminary work. By playing back a sequence of 5 I can fool my Windows machine (on another subnet) that the radio is present. It then appears in the list and allows me to connect over my OpenVPN connection. I have an Asus DSL-AC68U router with a built in VPN endpoint, it's trivial to set up and even provides an easy certificate export button along with links to allow download of the relevant client software. All of the required software is free. As I work with PCI/DSS compliance I am uncomfortable with port forwarding any ports apart from those required by the router to enable the IPSEC/L2TP VPN tunnel. The upside of a tunnel is that subnets inside the LAN may be projected to the remote connecting device.
Incidentally SmartSDR will hang if after the broadcast packets have been replayed the radio is either not online or a connection path does not exist. I would suggest a minor change to the program to handle the case where network comms fails or becomes unavailable.

Frank, HB9FXQ

https://github.com/krippendorf/flex6k-discovery-util-go using openvpn

Garry F. Fisher

The flex works fine and Maestro works fine when I am at home.  When I took it to the Library to try using on their WiFi system  I got the radio is not connected.  I brought it home and turn it on and it automatically came up and connected.  What do I need to do in addition to get this to connect outside the home QTH.  I have it registered and thought it would work now but it didn't.  What else do I need to try to use this outside of my home qth?
Garry​

Norm - W7CK

Is there a firewall or router issue?   I haven't researched it, but when I first set up SmartLink, I entered the required info into my routers port forwarding screen.  I couldn't for the life of me get a connection when outside my home.  I removed the port forwarding data and everything works just fine now.

Like I said, I haven't been home enough to investigate why the port forwarding didn't work like I thought it should.

Norm - W7CK

Garry F. Fisher

Thanks for your suggestion I will try to figure out how to remove the port forwarding data.
Garry