Server: Raspberry Pi - Bullseye
wfview: v2.03
Remote: Windows 10 Pro
wfview: v2.03
Radio: IC7300 - USB
Used to have connection from remote to server and things worked fine - a hiccup occurred with the audio, and in an attempt to fix it, upgraded both server and remote to wfview v2.03
Server IP address is unchanged. Port settings are correct. Can connect to Server using Remote Desktop and can control radio from wfview.
Log files : Remote: https://termbin.com/tbzi Server: https://termbin.com/eeek
Manual Radio CI-V Address - NOT CHECKED
Use CI-V address as Model ID - NOT CHECKED
Since this was working a week or so ago, the CI-V Transceive must be enabled. I have not been to the Server location for two months - don’t think it would change.
Port forwarding is setup on the Server end to route the ports to the Raspberry Pi. Again that has been functional within the last week.
You say you can control the radio with wfview. I guess you mean with wfview on the remote side over remote desktop? If do your radio must be correctly set up as Ci-V obviously work.
You can re-install an older version of Wfview if you give it another path when installing. I always do that when upgrading my remote to be sure I have a fallback if it does not work.
Then you can check if your remote connection still work with the previous versions of Wfview.
I recently had this problem and I thought that my port forwarding settings were correct, which they were if you just looked at the port forwarding. However, the thing was that both my client’s PC and the Server PC actually changed their IPv4 adresses! After changning these in both of the router’s settings it worked for me!