Has anybody tried Remote via VPN?

Beppe IK3VIG

Hi, as in picture: I do not remember ever having read anything on the forum about it. But I could be wrong.... 73 Beppe ik3vig

Stu Phillips - K6TU

Yes - but you must have a VPN which operates in BRIDGED mode otherwise the UDP packet broadcast by the radio won't be seen by SmartSDR and you won't be able to connect to the radio. With a bridged VPN, it works fine assuming you have adequate bandwidth. Stu K6TU

Beppe IK3VIG

Hi Stu. the big problem is DAX ! It requires up to 250 KB when ON (for remote listen) Normallly with two slices open the BW is close to 100 KB at any SPAN, using a confortable 15 FPS. 73 Beppe ik3vig

Beppe IK3VIG

This a picture of BW monitor: With DAX ON the BW pump UP to 250kB, without DAX the BW is +- 50kB

Tim - W4TME

Beppe - DAX is NOT intended to be used for remote access but for operating digital modes. It is intended to be used on a local LAN where 250k of bandwidth is not an issue or should be a concern. Optimized audio data streams are slated for a future version of SmartSDR.

George KF2T

But, Tim, we're "experimenters!" It is a fun exercise. Or at least I hope so - after crashing the rig running DAX via Skype from 450 miles away. Fingers crossed I didn't wind up doing something ****...

George KF2T

Follow up - the problem turned out to be power supply related, not a SSDR or DAX problem. I had been doing some cable changes before heading out and wasn't connected well enough! That'll learn me good ;-)

Steve-N5AC

DAX is not bandwidth optimized -- we are using VITA-49 in processing efficient mode and frankly sending stereo audio when mono will do. The DAX client is designed to be run locally with the radio and not for remote audio. We will be working on a remote audio solution later and we will be doing things in a much more bandwidth-efficient mode. We will likely cut the bandwidth in half on a DAX channel soon. I'm not sure that we will go to VITA-49 link efficient mode which will cut another 25% off the bandwidth because it increases CPU and DAX is really a LAN solution. We could also reduce the dynamic range from 24-bits to 16 or so and again cut the bandwidth by 33%. So it wouldn't be much work to go from 64 bits per sample to 16 for an overall bandwidth reduction of 75%. This would take a DAX channel from 1.536Mbps to 0.384Mbps. We're looking for user feedback on whether this is important or not. Also, I want to point out there are a couple of WAN timing issues that must be dealt with also (for full remote operation). There is jitter and latency. Today DAX requires fairly consistent packet rates that you will get on a LAN. That is the packets are evenly spaced. If the traffic becomes bursty, this results in jitter when you receive packets. The standard mechanism for combatting this is to buffer. This is one of the reasons why YouTube buffers for a while before showing you the video you want to see: it gets enough material locally so that when t starts playing it can grab a frame at the rate that it wants while the network side is stuffing in packets at an odd pace... first 10 then none then 5 then 15, etc. By inserting a buffer, though, you add a lot of latency. For listening, this is fine. If you are just listening you really don't care that the program material is delayed by 100ms or a full second or more. But if you are trying to respond to the other end (transmit) then you want as low latency as you can get. Optimizing the network traffic, latency and jitter is the bulk of the work that must be done for full remote operation. So we know that folks will play with VPNs in the mean time and we are interested in the results you achieve. But we know that in most cases these kinds of issues will prevent most operation from succeeding for the time being. The FLEX-6000 is designed with remote in mind and SmartSDR is optimized for remote operation. I know you guys are about to die waiting on it and so are we!

Bob Fuller

I'd like to put in a word of support for including the free, low bandwidth codec ILBC. I've tried many codecs and favor this one for mobile remote operation. ILBC supports dropped packets more smoothly than most other CODECs in a mobile (cell) VOIP data environment and offers above average voice quality Vs. Bandwidth & cost. Bob, W7KWS

Mike W8MM

RTCDataChannel?

Steve-N5AC

We've already picked a codec and have it working in the lab.  We are seeing 100x bandwidth reductions from full steaming data and the audio is virtually indistinguishable from the original.  It's freaking magic.

Asher - K0AU

Glad to hear you found a good codec.  Never an easy choice.  Please consider offering a codec option that's open and available on multiple platforms!

Steve-N5AC

Barring any serious issues, we'll be using Opus.

Asher - K0AU

Awesome choice!  Thanks.

Bob Fuller

Hi Steve, I should have been clearer in my advocacy for the ILBC coded. I am hoping for the inclusion of several codecs, selectable by the user on the fly. I have found that environment is a big factor in my choice of codec. One for an LTE link, a different one for DSL and still another for 2G. Often low latency is the dominate factor in choosing a codec but I will trade low latency and a bit of voice quality to be able to use my remote station via a 2G data link versus sitting around the camp site doing nothing but reading QST for the third time. Thanks, Bob, W7KWS

Steve-N5AC

Any time we spend integrating and testing with multiple codecs is time we could spend on other things if the codec we have is already good enough.  So, I'm naturally resistant to doing this, but I'm open minded.  Do you have any material (scholarly articles, etc) that would help make a case for doing this?

We will be doing testing with varying latency, dropout, packet shuffling configurations in the lab using a network mangler and then later over real links that have substandard performance so we will definitely be testing in the types of environments you are concerned about.

Bob Fuller

Steve,

I retired from engineering in 1998 so my academic experience is way behind the curve. The bulk of my data experience came in the late 1970s working on cellular development with Bell Labs. Even at that we weren't concerned with voice coding just command & control over a multipath channel with 30 dB fades, often below the noise level.

Your endeavor is probably much more difficult than mine was as you ultimately will want to please my goals of low bit rate remote control and some other customers desire to listen to music remotely from an HF broadcaster.

My suggestion is to proceed with a good choice or two but allow your customers to plug in other, optional codecs that suit their needs.

I did a quick Internet search and there are many articles on the subject.  More than I can study and make an informed suggestion. I have included a link below to one article that discusses some of the issues within the context of the AMR codec group which I believe that AT&T has standardized on for their mobile codec.  Of course, landline Internet is less rigorous than are mobile data links.

My recent experience is empirical doing amateur radio using several media over the last few years. Some links were slow some choppy others exhibited both and were useless.  Other links are perfect.  I've paid for some codecs and found others installed in various VOIP soft phones or hardware. I've found some are great in one context and then useless in another. This must be why most of the SIP VOIP implementations offer a large user selection of codecs. This way they can ultimately please the largest number of customers.

Sincerely,

Bob, W7KWS

http://telcodocs.p1sec.com/3GPP%20Rel-10/3G%20and%20beyond%20:%20GSM%20(R99%20and%20later)/22_series...

George KF2T

Anyone gone the VPN route and have success stories to share? A bridged VPN from home LAN to the world is sounding really good with 1.4 coming soon. Any service provider recommendations, or other advice?

K9SO

My son and I were able to convert the UDP multicast packets to unicast using a virtual linux machine running on the host computer. Those packets can be sent over the Internet. Doing the opposite at the client end to convert back to UDP, we were able to connect reliably without using VPN. 

3 yellow bars and a 70mS ping working well, even on CW between Chicago and Charlotte.

We're going to try and install a simple Linux plug on each end (~$14) to do this without a computer running other than the host. 

I wonder if anyone else has used this approach?

Fred, K9SO

Peter K1PGV

Steve asked for feedback regarding the desireability of decreasing the bandwidth that DAX uses. I vote an emphatic NO. DAX is meant for LANs and the only bandwidth li,mutation on a LAN is 1Gbs. Keep the full fidelity of audio on DAX. What would be nice is to be able to put one slice on the left channel and another slice on the right channel... But that's not really THAT much of an advantage over just running two instances of the digimode program. Peter K1PGV

Bjørn Ove Kristiansen

I for one have to say I disagree on this. Granted, I am new to using Flex, so perhaps I haven't quite gotten the grasp of all the features and possibilities of the radio and software yet, but it is my understanding that for proper and hassle-free use of data modes, you would want to utilize DAX. If that is the case, rhen DAX should be available for use on lower bandwidth connections as well to cater for those of us (myself included) who just do not have the option (physically) to run Flex on a local connection. Bjorn LB5TG

George KF2T

The only way I'd say "yes" is if DAX encoding can be improved without a loss of fidelity. For those with limited bandwidth in their LAN, using only one DAX channel (deselect unused channels) should not be a problem. If it is, the LAN does need improvement.

SteveM

It seems to me the solution is a simple one - no need to vote. DAX defaults to maximum fidelity, then automatically downshifts the bitrate to the capability of the link. This would be good enough, but to be perfect, it would also shift back up based on a longer time constant.

A nice feature would be to add a meter showing the current state of the DAX connection.

Mike W8MM

I'd like to refresh this discussion to see if I can make a VPN work for SmartSDR and K6TU's iPad Remote.  I can use PC LAN-Remote and Stu's iPad Remote on my home LAN with great ease and enjoyment.  It's just terrific.  I'd like to build on that so I can operate from the field or my office, as well.  And, I'm getting bored waiting for V2.0 of SSDR ;~}

Well, it seems harder than it first looked: 

My Panasonic IP telephone supplier and my Cincinnati Bell Fioptics internet provider, after much backing and forthing, settled on a Draytek Vigor3900 router to make my gigabit internet and VOIP SIP trunks work together correctly.  I am therefore permanently attached to this "Multi-WAN Security Appliance" and need to see what I can do with it for Flex-6XXX remote VPN service.

I tried a very nice free Draytek iOS app called "Smart VPN" on my iPhone 6 and my iPad Pro.  I set up the Vigor3900 per the FAQ http://www.draytek.com/en/faq/faq-vpn/vpn.ssl-vpn/how-to-use-smartvpn-ios-app-and-establish-ssl-vpn-to-vigor3900/  to use the SmartVPN app and it constructed a nice SSL VPN that works just fine to get inside my LAN.  I can get the right answer to "What's My IP" when connected through the VPN (I have a fixed IP at home) and also administer the Draytek using its 192.168.****.**** LAN-side address. I'm definitely connected to my LAN.

But, it doesn't play nice with finding radios with which to connect K6TU's Remote

The problem, of course, is that I am a complete VPN newbie and can't figure out how to configure the VPN connection for bridge mode or its functional equivalent.  I've perused the User's Guide http://www.draytek.com.tw/ftp/Vigor3900/Manual/DrayTek_UG_Vigor3900_V2.1.pdf and looked at every thread on this site that mentions VPN without finding anything promising.

Would someone of you knowledgable IT guys like to coach me through to a VPN solution?  

For fun or profit, ... your choice.

Mike - W8MM

Steve K9ZW

Chris K6OZY is the VPN go-to Elmer and has done a series of video tutorials:

https://community.flexradio.com/flexradio/topics/part-1-raspberry-pi-softether-server-setup-for-remo...

https://community.flexradio.com/flexradio/topics/part-2-raspberry-pi-softether-bridge-setup-for-maes...

https://community.flexradio.com/flexradio/topics/part-3-windows-softether-bridge-setup-for-maestro-r...

73

Steve K9ZW

Mike W8MM

Thanks Steve,

I've already watched them to no avail.

I thought about using SoftEther on a radio-close PC, but couldn't figure out how to "open port 5555" on my particular router.

Stu Phillips - K6TU

On iOS devices, you must use the system built-in VPN support because Apple does not permit third party VPN solutions to operate in BRIDGED mode for security reasons.

The built-in L2TP VPN support works very well with many third party VPN servers - my personal favorite because of its ease of configuration and robust security is the Soft Ether VPN server.

Note that for this to work with the FlexRadio, you must have the VPN Server and the radio on the SAME IP SUBNET.

For L2TP support, your Internet router/firewall must be configured to direct UDP ports 500 and 4500 to the IP address of the computer on which you run the VPN Server.

The link for the manual on your Vigor 3900 unfortunately doesn't open - I tried the Draytek site but couldn't get that to download the manual either.

Stu K6TU

K1UO Larry

Mike,  I am using the built in VPN on my ASUS routers at the remote and here at Home.  Nothing else to do  radio works fine.  I do need to use CWX for cw and my digital mode (RTTY)  works fine.  Not an SSB op so have not tried that mode .  Was waiting for Maestro for that.

 I use about 9 Meg up with everything opened up at the remote end and of course see the same 9Meg down here at the Control end so until WAN is implemented by Flex you do need good Bandwidth.  I can throttle back the Waterfall and get away with around 3 M uplink for the radio at the Remote end but I would think that would be minimum.

I am fortunate to have FTTH on both ends of my VPN link.

Regards

Larry  k1UO

Wim

I use the VPN build-into my Wireless Access Point, it's a Netgear R7000 and has easy VPN setup.

You just install the free OpenVPN Client on MAC or Windows and you plug in the configuration
file generated by the R7000 and that's it.

I worked my 6500 over VPN from Europe

Mike W8MM

Stu,

Thanks so much for the insight on what Apple allows for bridged support.  Sounds like L2TP is a must have for what I want to do.  I was originally going to configure Soft Ether for L2TP/IPSEC, but I couldn't figure out the setup with my router.

In the threads and videos talking about Soft Ether VPN configuration, it mentions "opening" port 5555.  The Draytek has "port redirection", is that usable?

Here's the firmware/documentation page with the Manual (V2.1) link: http://www.draytek.com/en/download/firmware/vigor3900/

I have no resistance to a best-practice solution (like Soft Ether),if I can figure out how to provision it!

Mike W8MM

Stu,

One more question:  Since I could only find "bridge mode" as "bridge VLAN" options, would that work, or do I need to get Soft Ether going, instead?