Rig-pty link not deleted on Exit Program

[K7MDL (Mke)]

Brief summary of problem (put in title as well): rig-pty link is not deleted on ‘Exit Program’ button. Result is wfView hangs on next startup.

Radio Model: Various
Connectivity (USB/Ethernet/Wifi/Other): LAN
Operating System: Pi OS bookwork on Pi 5
wfview version (press “About”): 2.04 Mar 10 2025 weekly build
Checked the wfview manual (Y/N): Y
Checked the wfview FAQ (Y/N): Y
Tried to google it (Y/N/NA): Y

What I did: Start wfView using virtual serial port set to rig-pty1. Then exit program using Exit button.

Expected behavior: Delete rig-pty1 on program exit (normal and unexpected if possible)

Observed behavior: Stale link is left behind rig-pty1 → /dev/pts/1 which blocks program startup later. Pressing Cancel Button deletes the link properly.

[K7MDL (Mke)]

I think the problem is a little more complicated.

(FYI, this is on a Pi5 with latest fullbuild install script)

I have seen cases where the link is deleted and where it is not. It is likely, at least sometimes, related to the way the program exits. On several cases pressing Cancel connection crashed the program leaving the link and the LAN connection (in this case an IC-9700) still showing active on the radio screen. Restarting the program results in greyed out window, likely trying to make a connection then failing.

Some background:
I have been making many runs capturing logs and trying to figure out what state each party is in. I am testing on a 705, 905 and 9700 building a Python based Band Decoder connected by CI-V over the virtual serial port. These test results are on an IC-9700. I looked at adding Pi GPIO code into wfView directly, but this seemed like a lower effort approach using wfView as a LAN to serial bridge. I tried to build wfView server but got build errors I was not able to fix. The main reason for the Band Decoder program is to have a LAN based Decoder fo the IC905 but it will support other CI-V rigs as well. Using wfView 2.X build for the increased IC-905 support.

I think the one problem (not the only one) I see is when the program crashes, rig-pty is closed but rig-pty is still open at the other end of the pipe so the link is not deleted. When running in my program, if I get a serial port closure exception, I test the rig-pty link and if it exists, I unlink it with Python’s os.unlink(rig-pty). That could get tricky if wfView is running but is a partial workaround. Most of these errors with rig-pty not getting deleted do not involve my program running.

When the stale links exists, the Radio’s LAN icon is OFF, my program is OFF, and I restart wfview, it comes up as normal and the link becomes active. So there is a lot going on and is a bit confusing still. I am still troubleshooting this more.

Below are some log capture for more context.

Here is a log snippet with a failure to open the pt

2025-03-12 17:25:14.912 INF default: Changing queue interval to 250 ms
2025-03-12 17:25:14.913 INF rig: creating instance of rigCommander()
2025-03-12 17:25:14.913 INF rig: creating instance of icomCommander()
2025-03-12 17:25:14.913 INF cluster: starting dxClusterClient()
2025-03-12 17:25:14.913 INF udp: Starting udpHandler user: "K7MDL"  rx latency: 150  tx latency: 150  rx sample rate:  48000  rx codec:  4  tx sample rate:  48000  tx codec:  4
2025-03-12 17:25:14.914 INF serial: Opened pt device:  33 , attempting to grant pt status
2025-03-12 17:25:14.914 INF udp: UDP Stream bound to local port: 53774  remote port: 50001
2025-03-12 17:25:14.914 INF serial: Opened pseudoterminal, slave name : /dev/pts/1
2025-03-12 17:25:14.914 INF serial: Error creating link to "/dev/pts/1" from "/home/k7mdl/rig-pty1"
2025-03-12 17:25:15.392 INF udp: udpHandler : Received I am here from:  "::ffff:192.168.2.46"
2025-03-12 17:25:15.392 INF udp: udpHandler : Received I am here 
2025-03-12 17:25:15.392 INF udp: udpHandler : Received I am ready
2025-03-12 17:25:15.392 INF udp: udpHandler : Sending login packet
2025-03-12 17:25:15.393 INF udp: Got connection type: "FTTH"
2025-03-12 17:25:15.394 INF udp: udpHandler : Received matching token response to our request
2025-03-12 17:25:15.394 INF udp: udpHandler : Detected connection speed  FTTH
2025-03-12 17:25:15.397 INF udp: udpHandler "Received radio capabilities, Name: IC9700, Audio: ICOM_VAUDIO, CIV: a2, MAC: 00:90:c7:0c:9f:2d CAPF: 5001"
2025-03-12 17:25:15.438 INF udp: udpHandler Got new radio time: ( 4078091 ) QTime(01:07:58.091)  Offset: 58637346 Calc time:  QTime(16:17:17.346)
2025-03-12 17:25:19.044 WRN qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
2025-03-12 17:25:49.595 INF udp: Got Radio 0
2025-03-12 17:25:49.595 INF udp: Find available local ports
2025-03-12 17:25:49.595 INF default: Received serial port baud rate from remote server: 19200
2025-03-12 17:25:49.595 INF default: Changing queue interval to 100 ms
2025-03-12 17:25:49.595 INF system: Delay command interval timing:  100 ms
2025-03-12 17:25:49.598 INF udp: udpHandler : Connection failed, wait a few minutes or reboot the radio.
2025-03-12 17:25:49.598 INF rig: Error using port  "192.168.2.46"  message:  "Connection failed\ntry rebooting the radio."
2025-03-12 17:25:49.598 INF udp: Closing UDP stream : "192.168.2.46" : 50001
2025-03-12 17:25:49.598 INF rig: closing instance of icomCommander()
2025-03-12 17:25:49.598 INF rig: closing instance of rigCommander()

Here is the case of Busy received

2025-03-12 17:43:19.682 INF audio: Output audio handler starting: "default"
2025-03-12 17:43:19.682 INF audio: Input audio handler starting: "default"
2025-03-12 17:43:19.682 INF udp: udpHandler Got serial and audio request success, device name:  "IC9700"
2025-03-12 17:43:19.682 INF udp: Got Connection status for: IC9700 Busy: 1 Computer  IP "0.0.0.0"
2025-03-12 17:43:19.682 INF udp: Got Connection status for: IC9700 Busy: 1 Computer  IP "0.0.0.0"
2025-03-12 17:43:19.683 INF udp: udpCivData : Received I am here 
2025-03-12 17:43:19.683 INF udp: udpAudio : Received I am here 
2025-03-12 17:43:19.716 INF audio: Output thread id 0x7fff996ef000
2025-03-12 17:43:19.716 INF audio: Output start() running
2025-03-12 17:43:19.716 INF audioconverter: Starting audioConverter() Input: 1 Channels of 0 48000 SignedInt 16 Output: 2 Channels of 0 48000 SignedInt 16
2025-03-12 17:43:19.735 INF udp: udpHandler Got new radio time: ( 5162355 ) QTime(01:26:02.355)  Offset: 58637380 Calc time:  QTime(16:17:17.380)
2025-03-12 17:43:19.735 INF udp: udpCivData Got new radio time: ( 5162355 ) QTime(01:26:02.355)  Offset: 58637380 Calc time:  QTime(16:17:17.380)
2025-03-12 17:43:19.735 INF udp: udpAudio Got new radio time: ( 5162355 ) QTime(01:26:02.355)  Offset: 58637380 Calc time:  QTime(16:17:17.380)
2025-03-12 17:43:19.743 WRN system: Data received before we have rigCaps(), aborting
2025-03-12 17:43:19.785 INF audio: Input thread id 0x7fff99eff000
2025-03-12 17:43:19.785 INF audioconverter: Starting audioConverter() Input: 1 Channels of 0 48000 SignedInt 16 Output: 1 Channels of 0 48000 SignedInt 16
2025-03-12 17:43:19.785 INF audio: Input start() running
2025-03-12 17:43:54.905 WRN qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
2025-03-12 17:43:56.491 INF udp: Got Connection status for: IC9700 Busy: 0 Computer  IP "0.0.0.0"
2025-03-12 17:43:58.744 INF udp:  CIV Watchdog: no CIV data received for 2s, requesting data start.
2025-03-12 17:44:19.244 WRN system: No response received to connection request
2025-03-12 17:44:19.245 INF audioconverter: Closing audioConverter() Input: 1 Channels of 0 48000 SignedInt 16 Output: 2 Channels of 0 48000 SignedInt 16
2025-03-12 17:44:19.272 INF audioconverter: Closing audioConverter() Input: 1 Channels of 0 48000 SignedInt 16 Output: 1 Channels of 0 48000 SignedInt 16
2025-03-12 17:44:19.273 INF udp: Closing UDP stream : "192.168.2.46" : 50003
2025-03-12 17:44:19.274 INF udp: Closing UDP stream : "192.168.2.46" : 50002
2025-03-12 17:44:19.274 INF udp: Sending token removal packet
2025-03-12 17:44:19.274 INF udp: Closing UDP stream : "192.168.2.46" : 50001
2025-03-12 17:44:19.275 INF rig: closing instance of icomCommander()

[phil (Phil Taylor M0VSE)]

If wfview crashes, then yes the pty symlink will not be deleted. The key is going to be working out what is causing wfview to crash.

If you press ‘cancel connection’ this means that wfview is not fully connected to the radio (the button text should be ‘disconnect’ when connected. There can be a number of reasons for this, usually it is because the radio responded in an ‘unusual’ way (sometimes this will require a reboot of the radio to clear). Obviously it shouldn’t crash wfview, but there may be a situation that we haven’t come across which confuses wfview?

This is almost impossible for us to diagnose without knowing exactly what your script is doing.

Phil

[K7MDL (Mke)]

Sorting this out is difficult for sure.

My project is posted on GitHub, run on a Pi co-located with wfView. I am using a Pi5 for the moment with the standard 64 bit desktop OS. There is an install script once you clone the repo.

https://github.com/K7MDL2/CI-V_Serial_Band_Decoder

Some of these issues occur with nothing connected to the serial port.

As I was typing this it ran for several minute then lost the WiFI connection to my IC-705.

USP packet loss is 421/258098. I get near zero on the IC-9700. There are very few bad packets reported by my managed switch. This was the last lines when it dropped. This did not crash, just lost connection. The pty like was properly removed. On my program it goes into an exception handler which is still under dev.

2025-03-13 02:23:34.083 INF rig: Unsupported command received from rig "2501000030" Check rig file
2025-03-13 02:23:34.144 INF udp: udpAudio : sending request for missing packet :  "0x216"
2025-03-13 02:23:36.244 INF udp:  CIV Watchdog: no CIV data received for 2s, requesting data start.
2025-03-13 02:24:03.327 WRN default: udpHandler : Radio rejected token renewal, performing login
2025-03-13 02:24:03.359 INF udp: udpHandler : Connection failed, wait a few minutes or reboot the radio.
2025-03-13 02:24:03.359 INF rig: Error using port  "192.168.2.52"  message:  "Connection failed\ntry rebooting the radio."
2025-03-13 02:24:03.360 INF udp: Closing UDP stream : "192.168.2.52" : 50001
2025-03-13 02:24:03.360 INF rig: closing instance of icomCommander()

As mentioned in another bug tonight, I am getting a lot of unsupported commands, most are 0x27 spectrum. I am doing noting with spectrum, just basic polling every 1 to many seconds for a few parameters for mode, split, and frequency related things to operate a band decoder. I have to wonder if the volume of those is behind some of this instability.

I am working on the serial port error handling to try to autorecover. The constant disconnects make for a good test bed :-).

Some of this is without a connection. I will try to isolate this better. Getting to the bottom of the unsupprted commnds might be a good first step.

[phil (Phil Taylor M0VSE)]

Unfortunately, the embedded WiFi within the IC-705 is not very good! The radio needs to be very close to the AP, and I have had best results with enterprise APs like Aruba/Cambium, some of the cheaper access points are just not very good at handling large volumes of UDP packets.

I will try installing your project and see if I can replicate the issues you are seeing.

Phil

[K7MDL (Mke)]

Thanks Phil.

I think the issue is related to the other bug report where I am sending to the radio with the 0x0 until I get back a CI-V address and switch to it.

My 705 is 12feet from the AP and the USBD error count is low.

The 9700 is near zero. The same LAN cable plugged into my 905 results in 50-60% bad UDP packets. I am also having RF Unit disconnects multiple times a day. I am going to take the 905 into Icom repair which is only 12 miles from me fortunately.

This is on my 705 after running for 1/2 hour.

I think using 0x0 for the radio address is a valid use case, as a workaround I did a quick logic change where I start off with the address of the 905, the radio is a 705, and then I wait for a message from the radio to arrive then I switch to that address and load the correct frequency table. I think at startup I can cycle through a list of known supported addresses until I get a reply from the radio and then not have to wait until the first message is sent to me. I wil try that tomorrow. is is after 4am now here.

Thanks for your help.

Mike K7MDL

[K7MDL (Mke)]

I had to try the workaround. At startup I send the ID request 3 times, one to each address in my list of radio I support today. 705, 905 and 9700. Messages to the radio with the wrong radio side address are ignored by the radio. The one good one responds and I use that address to set the radio model and load the correct frequency table. So I have a good workaround.

The upside with this discovery is that I know how to crash wfView which makes my testing the serial error handing code easier :-).

[K7MDL (Mke)]

Happy to report all looks stable, been running for 9 hours on the 705 no problem.

Numbers look good also.

[phil (Phil Taylor M0VSE)]

That’s good. I will fix the issue with the Transceiver ID command (\x19) causing issues, as it is used extensively by wfview for radio discovery as well (we just didn’t expect it to be used by external programs!)