Varanny

[bergie]

Varanny is a launcher for VARA modems. Varanny support in pat would enable the VARA (and rigctld) instance to be started and stopped automatically, conserving system resources.

When varanny is enabled, all varanny modems available in the network are discovered automatically via mDNS.

[martinhpedersen]

Thanks for the PR :)

Varanny support would be useful, but I do not think the current implementation has the right architectural boundary.

The proposal spreads Varanny-specific discovery, modem selection, session state, CAT handling, fallback behavior, startup, and cleanup across App, Connect, initVARA, and VFOForTransport. This makes generic application and connection code responsible for the lifecycle of an optional orchestration mechanism.

This is also producing concrete ownership and lifecycle problems:

• VARA listeners and outbound connections use the same modem accessor, but outbound cleanup can stop a Varanny session still needed by an active listener.
• Connect requires Varanny-specific cleanup at multiple return paths, and some paths can still miss cleanup.
• VFOForTransport independently selects or discovers a modem, so CAT/QSY can target a different modem from the active VARA session.
• CAT connections opened by VFOForTransport are not retained or closed.
• The dial-failure path checks and clears the HF modem for both HF and FM connections.

ListenerHub already implements part of the desired pattern for listener mode. It initializes listeners, retries failures, tracks active listeners, and closes them centrally. However, it does not manage ownership of the underlying modem when that modem is shared between listening and outbound connections.

I have opened #545 to propose a complementary lifecycle abstraction for stateful modem transports. It would manage modem initialization, health checks, reuse, ownership, associated CAT/VFO resources, and cleanup, while ListenerHub would remain responsible for listener behavior and accept loops.

The initial implementation does not need to generalize every modem. It can focus on VARA HF/FM and provide:

• A common acquisition path for listeners and outbound connections.
• Safe reuse between multiple users.
• Modem-associated VFO/CAT resources.
• Direct and Varanny-managed provisioning behind the same application-facing abstraction.
• Implementation-specific discovery, selection, startup, readiness checks, and shutdown.
• Centralized cleanup without Varanny-specific handling throughout Connect.

With that boundary, application code could request a VARA modem without knowing whether it is connected directly or managed by Varanny. app.go would not manage mDNS discovery, VFOForTransport would not perform discovery, and releasing an outbound connection could not stop a modem still held by a listener.

I consider #545 a prerequisite for this PR. Once that lifecycle boundary is available, Varanny can be implemented behind it rather than as cross-cutting application state.

[bergie]

Ok, in the meanwhile are you OK with leaving this PR open, as the implementation here works.
It is easier to refactor working code.