Bug 2218894

Summary: Hamlib NET rigctl connection of Gqrx with WSJT-X does not work anymore
Product: [Fedora] Fedora Reporter: Daniel Rusek <drusek>
Component: hamlibAssignee: Richard Shaw <hobbes1069>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 38CC: denis, hobbes1069, jskarvad, lucilanga, mail, mdblack98
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-05-28 13:17:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Gqrx remote control config
none
WSJT-X remote control config none

Description Daniel Rusek 2023-06-30 13:26:26 UTC
Originally reported as rhbz#2218889, but it seems to be a hamlib regression.

I am using a Gqrx SDR in combination with WSJT-X. Everything used to work fine, however it looks like that the Gqrx control in WSJT-X using "Hamlib NET rigctl" recently stopped working. See the additional info for complete error message from WSJT-X. Also see the attached screenshots for my rig control configuration.

"nc 127.0.0.1 7356" seems to work fine and I can communicate with Gqrx, set or read frequency etc. without any problem, however the rig control in WSJT-X does not. It also happens with Flatpak version of WSJT-X that uses the same (4.5.5) version of hamlib and downgrading Gqrx did not help which makes me believe that it is actually a hamlib regression.

Reproducible: Always

Additional info:
Hamlib error:   2:rig.c(7481):async_data_handler_start entered
async_data_handler_start: async data support disabled since async_data_enabled=0
  2:rig.c(7488):async_data_handler_start returning(0) 
rig.c(254):add_opened_rig returning2(0) 
rig_open: 0x562b105dab2c rs->comm_state==1?=1
  2:rig.c(6084):rig_get_powerstat entered
rig.c(6104) trace
netrigctl_get_powerstat called
netrigctl_transaction: called len=15
rig_flush: called for network device
network_flush called
write_block(): TX 15 bytes, method=2
0000    5c 67 65 74 5f 70 6f 77 65 72 73 74 61 74 0a        \get_powerstat. 
read_string_generic called, rxmax=1024 direct=1, expected_len=1
read_string_generic(): RX 7 characters, direct=1
0000    52 50 52 54 20 31 0a                                RPRT 1.         
  2:rig.c(6109):rig_get_powerstat returning(0) 
rig_open: rig power is off, use --set-conf=auto_power_on if power on is wanted
Rig is not powered on
Rig is not powered on
 while opening connection to rig

Comment 1 Daniel Rusek 2023-06-30 13:29:54 UTC
Created attachment 1973406 [details]
Gqrx remote control config

Comment 2 Daniel Rusek 2023-06-30 13:30:23 UTC
Created attachment 1973407 [details]
WSJT-X remote control config

Comment 3 Richard Shaw 2023-07-11 11:20:33 UTC
I can post on your behalf, but have you posted this to the linuxham mailing list? Michael is pretty responsive. Since the package is the latest release version there's not much I can do. I will send Michael an email linking to this BZ though.

Comment 4 mdblack98 2023-07-11 12:58:12 UTC
This has been fixed with a new rig entry in Hamlib for Quisk if you are using that?
Also a fix was added for SDR++ and Flex.

Should work for any other SDR program trying to emulate rigctld with incomplete capability.

Mike W9MDB

Comment 5 Daniel Rusek 2023-07-14 13:08:39 UTC
(In reply to Richard Shaw from comment #3)
> I can post on your behalf, but have you posted this to the linuxham mailing
> list? Michael is pretty responsive. Since the package is the latest release
> version there's not much I can do. I will send Michael an email linking to
> this BZ though.

Nope, I did not post this to the linuxham mailing list. It would be great if you could post it on my behalf. Thanks a lot!

Daniel OK2VLK

Comment 6 Aoife Moloney 2024-05-28 13:17:36 UTC
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.