Ok, I know I'm doing something weird, but bear with me.
Rig is a Flex 6300. I am using -m 236 for the argument for rigctl, but I'm posting from memory here, so it may not be right in this post. Rest assured it is correct in my configuration.
I can configure CQRLOG to use a flex virtual TCP port on my local windows machine, and it works. The rigctl argments in this case are:
/usr/bin/rigctld -m 236 -r windows1.mydomain.com:60001 -t 4532
The issue is that I frequently also operate my flex from a remote machine. When I run from that machine, I need CQRLOG to connect that machine for rig control instead of windows1.mydomain.com. Another caveat is that, since this is a laptop, I may also run it from any random place on the internet. So, I thought that reverse SSH tunnelling was my saviour.
I create a reverse ssh tunnel from my windows client machine to my cqrlog machine (let's call that cqrlog.mydomain.com). The windows side is set to the TCP port for the flex virtual serial port on the windows machine, and the cqrlog side is set to port 60001. The SSH arguments I end up using on my windows client are something like this:
ssh -R 60001:localhost:60001 myname@cqrlog.mydomain.com
This ends up being the rigctl params I use in CQRLOG:
/usr/sbin/rigctld -m 236 -r localhost:60001 -t 4532 (I've also tried with my FQDN here instead of localhost and gotten the same result)
This way, I could theoretically make CQRLOG connect via localhost:60001 via the SSH tunnel to the flex software running on pretty much any client I wanted from anywhere on the internet. Neat, huh?
Well, the problem is that CQRLOG doesn't seem to like this. Everything connects as I want it to, but CQRLOG doesn't get frequency or mode info from the radio.
What is REALLY confusing is that, after CQRLOG starts rigctld with those arguments, I CAN, from cqrlog.mydomain.com, open a telnet connection to localhost:4532 to the rigctld daemon, and type "fmv" and other commands into the telnet window, and actually get the expected responses from the radio! But for some reason, CQRLOG is not able to do the same thing!
As far as my telnet window to rigctld is concerned, everything is fine, and the SSH tunnel is working just like when I have rigctl connect to the windows1.mydomain.com:60001. I am completely stumped as to why CQRLOG can't get frequency info from the same rigctld instance and my telnet window can, and that it's only broken when the SSH tunnel is in use under the sheets.
I'd appreciate any suggestions.
73,
Bill WK2X
Hi Bill!
Interesting setup. I had to read your message few times to understand the case. And I'm still not sure... Sorry, reading this while morning coffee. Perhaps I'm still sleeping.
Ok. Let's start with ssh reverse tunnel. I have never tested reverse tunneling ("-R") instead I have used "-L" for VNC forwarding. I assume "-L" would work also in your case. Your cqrlog machine connecting to localhost:60001 would be forwarded to windows1.mydomain.com:60001 where the radio is.
1. start "cqrlog debug=1" from command line and look what is the response for "fmv" (when running ssh -R)
2. Try "-L" instead of "-R" with ssh
3.If "-L" is not the solution and yo say you can telnet localhost:4532 and get rig connected from cqrlog machine then try to start rigctld from command line with rig "-m2" and the forwarded address as "-r" parameter.
Then set up cqrlog for rig 2 (Net rigctld) localhost:4532
It should now get connected to command line rigctld that then connects over secure forwarding.
4. That is complicated. Lets drop one rigctld away. Assuming your radio runs under windows machine. Why not starting rigctld there? There is hamlib for windows, too. Then just connect to 4532 there via secure channel. That case cqrlog setup uses rig 2 (net rigctld) at normal localhost:4532 address that is forwarded via ssh -L 4532:4532
This case is same as starting rigctld locally from crontab and then connecting cqrlog to it, now the rigctld is just behind ssh tunnel.
In all cases remember to open firewalls!
--
Saku
OH1KH
Hi Saku,
Thanks for your help - I think I have a solution / work-around.
> 1. start "cqrlog debug=1" from command line and look what is the response for "fmv" (when running ssh -R)
That's the first thing I did. CQRLOG gets no response from the "fmv" command. What's weird is that a telnet connection to the same instance of rigctld DOES get the appropriate response. I'm baffled as to why CQRLOG does not, when it is connecting to the same rigctld instance as my telnet window.
> 2. Try "-L" instead of "-R" with ssh
That did not work at all. The listening socket ends up on the wrong host this way, so no connection from CQRLOG is possible.
> 3 and 4 [snip]
This actually seems to work. I'm able to run rigctld locally on the flex client machine, and CQRLOG seems to behave well with it. I think this will be an acceptable work-around...but I still would love to know the crazy reason behind the difference I saw between CQRLOG and the telnet window when running the other way. ;)
73,
Bill WK2X
Hi Bill!
Nice to hear that you got 3/4 working.
But I will return now to beginning.
You say you use model -m236, do you have rigctld version <4.0 ?
From 4.0 the model is -m2036. They have changed rig model numbering.
If you have flex virtual serial2TCP port at windows machine 60001 open for connections I can not understand why you need reverse tunnel.
To connect from cqrlog.pc to windows.pc I would use:
ssh windows.pc -L 60001:localhost:60001
Then from cqrlog.pc I could find flex virtual port at localhost:60001
So cqrlog TRXControl should have:
Radio one, desc: Flex 127.0.0.1
rig model : 2036 device: 127.0.0.1:60001 poll rate: 2000 port: 4532
Run rigctld when program starts (checked)
Rest of settings: Default
If Flex virtual port is serial2TCP type this should work.
How ever doing this may require external paremeters to adjust rigctld. These are: write_delay, Post_write_delay, timeout and retry.
Using virtual serial port via TCP and even via internet may cause delays that affect to rigcltd.
Other thing may be that sending "fmv" from telnet console or from cqrlog may cause different TCP traffic. You should compare their effects to tunneled port with tcpdump, but that is unfortunately impossible because of secured connect.
I would not try to tunnel the serial2TCP port.
Running rigctld at windows.pc and tunneling the TCP connection from cqrlog.pc to rigctld is TCP traffic that is normally already done between cqrlog and rigctld in local setups.
Another solution instead of ssh would be OpenVPN that could give access also to other services of home network when travelling. (that is in use here)
--
Saku
OH1KH