Bug 2218894 - Hamlib NET rigctl connection of Gqrx with WSJT-X does not work anymore
Summary: Hamlib NET rigctl connection of Gqrx with WSJT-X does not work anymore
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: hamlib
Version: 38
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Richard Shaw
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-30 13:26 UTC by Daniel Rusek
Modified: 2024-05-28 13:17 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-05-28 13:17:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Gqrx remote control config (16.44 KB, image/png)
2023-06-30 13:29 UTC, Daniel Rusek
no flags Details
WSJT-X remote control config (80.09 KB, image/png)
2023-06-30 13:30 UTC, Daniel Rusek
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.