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

Frank, HB9FXQ

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.

K6OZY

2.0 will solve this issue.  They may add this feature prior, but I wouldn't bet on it.  This issue arrived when Marcus (Author of the IOS version) added this feature that was not in sync with the Maestro/Windows versions.   They implemented this restriction to prevent people from port forwarding their radio through their firewall since there is currently no authentication on it.   I am not defending this decision, simply stating it.

Jim Gilliam

I have tried to use SmartSDR with OpenVPN in my iPhone and using the OpenVPN server on the Linksys router. When I bring up iSmartsdr the radio is not discoverable. It would really be great to enter the I/P address and the radio would magically appear. The problem with Linksys OpenVPN ( I guess) is that it provides the client with an I/P address that is not on the LAN. I don't know enough on how to overcome this problem.

Jim, K6QE

K6OZY

OpenVPN has two modes.  TUN & TAP.   You want to use TAP mode so your client gets an IP in the same subnet.  If those options aren't available to you, then your OpenVPN server is too "simple" and hides those options from you.

Frank, HB9FXQ

This plastic router devices often hide advanced VPN features. We found some semi-prof. hardware ( https://twitter.com/HB9FXQ/status/770303108681437184  /  http://pcengines.ch/apu.htm) and run PfSense on it. Requires some good network knowledge, but I'll post some detailed documentation about our setup soon. I'll announce it here in the forums then. 

K6OZY

I use pfSense extensively too and wrote up an article already on using OpenVPN on it.

Unsupported SmartSDR 1.4 over WAN using OpenVPN HowTo (pfSense Firewall)

K6OZY

pfSense can be installed on any commodity hardware, but I like to support the pfSense team.   I'm currently using https://store.pfsense.org/SG-4860/.

My prior model was an SG-2220.  They have released a cheap $150 unit that is Super small:  https://store.pfsense.org/SG-1000.aspx

Frank, HB9FXQ

Let's see if there'll be an official statement from the staff this time. @Steve @Eric

I don't like the idea, that preventing users from doing dump things like unsecured port forwarding. Nobody saves me from opening all my ports to a unsecured old Windows XP machine, just because it is a dump idea. Even if flex would offer a WAN feature, I'd stick to my VPN setup, because it's under my control. Open source and I can do propper enterprise grade authentication, regenerate certs / use good auth relams etc. 

K6OZY

I agree with this statement.  I do not like them restricting the client "for my safety".  I too will continue VPN usage with 2.0.  My guess is liability or support issues.  It is ultimately their choice.

Frank, HB9FXQ

Seen your posts. Great work! Basicly that is what we've done. I've also included IP switchable power sockets, SPE PA Control and a small html dashboard to start/stop radios via relays on the REM port, control accessories like antenna switches etc.  Enjoy that setup very much

Jim Gilliam

Thank you, gentlemen, for the lucid advice. Never knew about Tun and Tap. It seems everyday there is a new term or acronym to add to my miserable knowledge of networking.

Jim, K6QE

Steve-N5AC

​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.

Mark G Thomas

The "for my safety" speculation makes no sense, because this is a limitation of the Maestro/Windows SmartSDR client, not a limitation of the Flex-6xxx radio server.

As a networking/security professional, this is an especially frustrating limitation as it's basic level functionality I take for granted an just about all other networking systems I use. I just keep hoping that if enough people ask, maybe FRS will add a box to SmartSDR and Maestro where an advanced user can type in a specific IP address to connect to instead of relying on broadcast discovery.

Steve-N5AC

Mark, FYI we have already added fixed IP to both Maestro and the radio.  This will be released in v1.10 which will be available soon.

Ria

I would second pfsense. We use it in the datacenter to handle about 2GBps of traffic. I use it at home on an atom box, at that time I needed more than what pfsense had in their h/w offerings. Even have IPv6 and RADIUS running on it as well as multi-wan and wifi APs as well as VLAN trunking for various subnets tied to Wifi SSIDs. Better than any home router. 

Frank, HB9FXQ

Thanks for all that background info. Explains it well, but for now we need a solution: 

Since our radios are already deployed we don't want to wait for 2.0, it leads me even more workarounds Tried to realize it with iptables and routing tables, but what happened was more something like: 

https://twitter.com/Cannibal/status/787861071931461632



I starded to hack a "Discovery packet relay app". Since we anyway have allways-on raspberry pi on all sites for monitoring / watchdog purpose I'll run that relay server/client on all sites. It captures and packs the discovery packages from the local subnet into routable packages, forwards it, the client then unpacks it, thenbroadcast it on the target site to  255.255.255.255:4992.

Sounds ugly, but works like a charm. Looking forward to complete it the upcoming weekend and will publish on github. Hope SmartSDR 2.0 will be available soon and I can delete that repo.

vy 73
Frank 

Ross - K9COX

http://www.reuters.com/article/us-cyber-attacks-manufacturers-idUSKBN133199