wfserver and LAN support for remote Transceiver via Internet

Feature Requests
1

I have been working on a headless wfserver installation on a Raspberry Pi 4 (Raspberry Pi OS Bookworm) and would like to ask whether wfserver could be adapted to support an Icom radio via its LAN interface without requiring a local USB/serial CAT interface.

The reason: I only have single-user access to the remote transceiver, but I want to access it from multiple PCs using wfserver.

My setup is:

Windows 11 / wfview
    192.168.3.xx
         |
         | wfview server connection
         | ports 51001 / 51002 / 51003
         |
Raspberry Pi / wfserver
    192.168.3.yy
         |
         | Icom LAN / UDP
         |
IC-7300MKII
    Internet Adress

The normal desktop version of wfview works correctly with the IC-7300MKII via its Icom LAN interface.

My goal is to run only wfserver on the Raspberry Pi and use a Windows wfview client. There should be no USB CAT interface and no local audio hardware required on the Raspberry Pi.

I modified the current source so that wfserver can operate in LAN mode and can successfully establish the initial Icom LAN connection. The server receives the radio capabilities correctly:

Model: IC-7300
CIV: 0x94
Name: IC-7300MK2

The connection to the radio on UDP port 50001 also works.

The Windows wfview client can then connect successfully to wfserver on ports 51001, 51002 and 51003 and receives the radio capabilities.

The problem occurs when wfserver requests the CIV/audio streams from the IC-7300. The IC-7300 responds with:

error = 0xfffffffc
civport = 0
audioport = 0

Therefore no CIV or audio stream ports are returned.

For example, the wfserver log reaches:

Starting icomUdpHandler
Received CommReady!!
Setting rig ID to: 0x94
Received new rigCaps for: "IC-7300" CIV: "94"
Received I am here
Received I am ready
Sending login packet
Received matching token response
Got Radio 0
Received serial port baud rate from remote server: 19200
Starting icomUdpCivData
Starting icomUdpAudio

but the stream request receives the above error from the radio.

I also verified with tcpdump that the initial Icom LAN control communication works, while no usable CIV/audio stream ports are subsequently established.

The stream request contains valid local UDP ports. I also tested the audio parameters with the values used by the normal desktop version (48 kHz / codec 4), but the IC-7300 still returns 0xfffffffc.

At this point I am using the normal desktop wfview server, which works reliably, so this is not urgent for me.

My question is therefore mainly whether you think wfserver could be modified to support this architecture properly:

wfserver
    -> Icom LAN
    -> IC-7300MKII

instead of requiring:

wfserver
    -> local USB/Serial CAT
    -> IC-7300MKII

If this is technically possible, I would be happy to test a modified version on the Raspberry Pi.

I can also provide the relevant source changes and complete wfserver logs if that would help.

73,
Frank / DL4EM

2

Hi Frank,

What you might want to do is dump the UDP traffic on a normal wfview to icom radio session. There are many subtle details. Or, look very carefully at how wfview client sets up and maintains a UDP session with the radio in the source code.

–E
de W6EL

4

Hi @emilywhite , can you tell us what UDP is, in fine detail? That might help.

Thanks,

—E

de W6EL