I have an IC-7300 connected by USB to my shack computer running Debian bookworm. I have configured wfview on this as a server.
On my laptop (W11) I have a client wfview connected to the server wfview. I connect other apps (WSJT-X and my homebrew logger) using rigctld. I can connect the client wfview audio to the laptop’s mic/speakers if I want SSB or to a headset plugged into the laptop for the same or VB-audio virtual cables for WSJT-x.
Unfortunately to switch between the various audio connections I have to change settings in wfview, then save settings, close wfview and restart it. Why? Why doesn’t the settings change happen without having to restart the program. The apps I develop are able to do so.
You can switch audio so long as you disconnect first.
Disconnect. Change audio devices (and other audio parameters), reconnect.
Alternatively, you can create desktop launchers which launch wfview with a different set of settings. That is how I do it. I have one for wfview-fldigi and one for wfview-voice.
I was aware of using different shortcuts and have two separate ones for connecting within and outwith my home LAN. These are static configurations. It’s dynamically changing the audio I was asking about.
Last night I was testing the connection from my local club and was failing miserably to get any audio out. When I got home I checked the port mapping on my router and saw I wasn’t mapping port 50003. D’oh!
Having fixed that eventually managed to change audio configuration dynamically, so thanks for that. It is prone to error as occasionally the wfview server on my shack computer crashes, when I do things in the wrong order on the client wfview.
Mapping ports to anything inside your LAN is potentially a security issue.
Suggest you implement a VPN from your remote computer to your LAN. This will make your remote computer part of your local network.
The VPN is usually implemented by the router. Some routers are better than others.
David
G8JXA / N1OL
I am aware of the security risk, and am taking measures to reduce these. The services on ports I’ve opened up are all password protected and I am about to make the external port numbers less like the internal port numbers I am opening up. Unfortunately my router does not seem to offer the functionality of a VPN server, which is what I think you are suggesting. I think it can divert all incoming port requests to a device that I can host a VPN server on, but that’s getting beyond my capabilities.
I definitely do not require the anonymity provided by commercial VPN servers.
Just found that out. Not sure what the ICOM protocol has to do with it, though surely if I specify control port = 49997 on the wfview settings page, it would use that to connect to the server wfview with my router converting it to 50001 on my LAN. And by implication (a dangerous concept I know), it would then use 49999 for the audio port which my router converts to 50003.
However I’ve restored the original router mapping.
The server (by default) will listen on ports 50001-50003. When the client connects to the control port (50001) the server sends a UDP packet telling the client where to find the CIV and Audio (50001 and 50002 by default), this is part of the Icom protocol. The ports need to be the same as if you create an inbound NAT on your router from 49999 → 50003 how does the client know to use port 49999 and not 50003?
I hadn’t realised that the port numbers were handled like this. I just assumed that the port numbers were three consecutive numbers and the user could just specify the base. I presume the ICOM protocol is the one used for ethernet connected transceivers. Mine is the IC-7300, so USB connected.
Phil Taylor knows what he’s talking about as he is probably the one person outside of Icom that really understands this protocol. Trust me, do not re-map the port numbers, they are communicated within the protocol. Yes, even for your radio. wfview follows the Icom protocol.
Alsno note that we do not support a VPN. If it works, fine. If it doesn’t, you are on your own.
(I have all the UDP ports open, let me know what you found).
Put “open ports security risk” into Google and read some of the articles.
In essence, with a VPN the remote computer becomes part of the local network.
Without open ports from the outside the only device a bad actor can talk to is the router. Most routers are locked down so difficult to break into. When you open a port a bad actor can talk directly to the device behind the open port and exploit any vulnerabilities.
That was the piece of understanding I was lacking. That the wfview server is emulating an IP connected Icom transceiver.
As the OP, I am happy with the methodology of disconnecting the “radio”, change settings, save settings, reconnect “radio”. Even if the “radio” is the wfview server. And even though I did it several times this afternoon, didn’t manage to crash the wfview server.
There are a few factors at play here.
How safe do you want to be.
How easily would you like to connect.
I’m not going to take sides on this… Running a VPN is a great idea, but it also has drawbacks and limitations.
Can one’s own existing device offer VPN functionality?
Is it the most practical solution?
Will it create any other issues?
Does one of the time and know how to implement it?
I share my radio with a student who is studying to become licenced, and i want them to have access to my radio, but not my whole network, a simply configured VPN is a bad choice here.
But to the original question… what’s at risk if ports X, Y and Z are open???
Possibly nothing at all!
Or… everything.
That’s the problem, no one can say for sure that there is a yet undiscovered security issue in Icom firmware or WFview.
And that’s the gamble.
I know a little about this stuff, but am not en expert.
I’d judge the risk to be low… but not nil.
I think most resonable people would agree with this assessment.
