Update: SmartSDR version 3.0.27 disconnecting from DXLab Commander

Dave AA6YQ

Last week, I released Commander 14.1.6, which disables SmartSDR's "keep alive" option (a possible source of TCP disconnects) and logs any Commander-initiated closure of the TCP port even if "log debugging info" is not enabled. These changes have not eliminated all reported TCP disconnects between Commander and Flex Signature radios running SmartSDR version 3.0.27; the diagnostics indicate that the disconnects are not being initiated by Commander.

My advice to Flex Signature radio users is still "remain with SmartSDR version 2.4.9 unless you have a compelling reason to upgrade."

Further progress on identifying the cause of these TCP disconnects requires a version of SmartSDR that can be configured to log unexpected events to a local file.

Many thanks to Dave G7HJX, Roger N3RC, Rick WR0H, Ronald W4RJF, Jamie WW3S, Chris N6WM, Mark W3II, Dave NX6D, Jeff KI0KB, Tim WA5YOM, John K3MA, and John K1ESE for their help with this effort.

K1UO Larry

Dave,
Do you think this is a local LAN thing?  I run 3.0.27 with DX Commander and the connection stays rock solid albeit either over the VPN to the remote via Softether or via Smartlink connections.  Guess I was completely unaware of this problem until reading about it here.
Good luck and thanks to all for chasing this.

Dave AA6YQ

There's no way to know, Larry, as there's currently no practical way to determine whether or not SmartSDR 3.0.27 is initiating the disconnections and, if so, why. Eric KE5DTO has initiated a request to extend SmartSDR to log errors and unexpected events to a local file; when this has been implemented, tracking down the root cause should be straightforward.

The known facts are

1. no one reported TCP disconnects between Commander and SmartSDR 2.3.9 or 2.4.9.

2. Commander is not initiating the TCP disconnects some ops encounter with SmartSDR 3.0.27.