ssdr disconnects

K6TD

Having problems with a new remote user getting dropouts and disconnected.

The release is 3.1.12. The radio is a 6700. The remote connection is via softether VPN. New user - never worked before. Testing with RTTY only

The user experiences dropouts for both RX and TX. Within a 3-5 minute interval, ssdr will say it's lost connected, and then automatically reconnects. Radio hasn't crashed.

We've eliminated WIN10 firewall, local to the user WiFI, and VPN, as causing the issue.

Other users are able to successfully use the setup, at the same time (using another radio in the remote shack).

Anyone experience this, or suggestion where to look, or how to diagnose this problem?

Thanks.

73, K6TD

Ha Gei

Nothing had like this.

Does softethernet reconnect ? or is VPN link stable ?

What happens if does soemthing like video or music via that link ?

Harry

John KB4DU

I would first confirm that other users can use the 6700 through the vpn, etc. If that is the case it seems the remote end is the issue. What is being used for remote? PC, router, network provider, etc?

Mike-VA3MW

@K6TD

You have eliminated those items that you have control on. Now, the hard part, and that is the actual network between you and the radio.

First, we did improve the network communications on 3.2.39 with the new IP stack in the .NET framework. You should upgrade to that and see if it improves. Many have seen improvements, my self included.

The hard part is now isolating the part of the network that is doing the hickups. Since you are now moving uncompressed audio over the VPN to the user end, that can put a lot of streaming strain on things. How fast is your upload speed? Have you done any measurements for bufferbloat? (www.dslreports.com/speedtest)

The audio stream are UDP packets and if your network becomes congested, those packets get dropped resulting in audio breakup between the radio and the user.

While other users have been successful, the differences are the ISP, the Routers they use and their network latency. Sadly, it is somewhat hard to diagnose. I have used LANSpeedTest to hammer away at a network and see how it breaks.

It could also be a Network switch that is flapping. You have to consider every part of the network the data passes through as part of the bottleneck. Just like an HF antenna. It could be any patch cord, antenna switch, RF cable or Balun.

Part of the reason we recommend using a remote PC at the radio end is to ensure we get all the Audio data sent to our Digital Audio programs like WSJT or FLDigi. When you send them over the internet you will have audio packet loss.

Here is a sample from my SmartLink connection to my station. Before 3.2.39 I have never seen this low an RTT or such a low packet loss. My ISP uplink from the radio is 5mb/sec but I use less than 1 mb/sec.

73

KD0RC

@K6TD , have you tried using SmartLink instead of SoftEther for the SmartSDR connection? In my remote operation, I use SmartLink for SmartSDR and SoftEther to connect a homebrew box with knobs and buttons (TeensyMaestro). Like Mike suggests, I keep an old laptop connected at the radio site and use TeamViewer for everything else.

On its maiden voyage, I used this setup with a cell phone hotspot providing WAN connectivity. The cell service was terrible, but it all worked. It wasn't contest grade, but for casual operation, it was great.

With a reasonable WiFi connection (rather than my back-woods cell phone connection) this would certainly be contest-worthy.

K6TD

thanks All for the comments and info. From this info, and more testing we've done, seems like the problem is with the internet link at the new user.

Will report when we get to the bottom of the problem.

Mike - thanks for the info about the new stack used in 3.2.39. I've been reluctant to upgrade software yet.

73, K6TD

Mike-VA3MW

No problem

If you want to use SmartLink, you will need to upgrade. No older version will work on SmartLink.

As well, the SmartLink connection compresses the RX and TX audio so that the payloads are smaller and requiring less bandwidth. When you use a VPN to connect to the radio, you will require more internet bandwidth.

73

K6TD

Following up...

The basic problem was IP path problems - occasional complete packet loss, often high latency (>300ms), and always high jitter (>45ms).

The VPN client is softether. This says the protocol stacking is: ssdr UDP; softether TCP; IPsec; link media

With the high link problems, TCP may "backoff" it's retransmit window. We measured ping times over the softhether VPN greater than 1.5 seconds, but always less than 2 second. With this long of a gap, ssdr would not hear the UDP broadcast for longer than 21 second, and disconnect from the radio. Of course, ssd would very quickly hear the UP broadcast from the radio, and reconnect.

The solution in this case was to use L2TP as the VPN client. Of course, there were still plenty of audio gaps, due to the link problem, but, those were acceptable for the contest we entered.

Thanks All!

73, K6TD