You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
FreeDMR/docs/release-notes-v1.5.0.md

4.1 KiB

FreeDMR v1.5.0 release notes

FreeDMR v1.5.0 introduces HDStack, a multi-process deployment for the standard container. It raises aggregate HBP capacity by distributing active hotspot and repeater sessions across up to five FreeDMR workers while retaining the existing 100-connection boundary for each worker.

Before upgrading

  • The standard container now chooses the number of HDStack workers from the available CPU count minus one, clamped to one through five. Set HDSTACK=1 explicitly to retain the established single-process layout.
  • Set HDSTACK_BASEID to the aggregator server ID. Workers use successive IDs beginning at HDSTACK_BASEID + 1.
  • The read-only FreeDMR container requires a writable /tmp. The shipped Compose file provides this with tmpfs: /tmp; retain that setting in custom deployments.
  • Existing deployments must update their Compose configuration to receive new services and mounts; pulling the FreeDMR image alone does not rewrite an existing docker-compose.yml.

HDStack

  • New HBP sessions are assigned round-robin across workers. A DMR ID remains pinned to its exact worker port for the active session, preserving its login, bridge and OPTIONS state.
  • A no-HBP aggregator owns external FBP and OBP relationships. Workers connect to it over private FBP v5/FBCP links.
  • Each worker has an isolated Loro playback process and private ECHO link when ECHO is enabled.
  • The reporting MUX presents worker reports through the existing reporting socket. It prefixes system names with the stable worker number, for example 1:SYSTEM-001, to avoid collisions.
  • The optional separate bridge.py process is disabled by default. Set HDSTACK_BRIDGE=1, assign it a distinct server ID and configure its skeleton config and rules files when bridge routing is required.
  • HDStack does not provide active worker failover, live migration or persistent session affinity. A failed worker's active sessions are not moved.

See HDStack multi-process deployment for configuration, generated ports, reporting and operational limitations.

Data Gateway

New installations include the stable FreeDMR Data Gateway container. Each worker has a direct FBP v5/FBCP relationship to the gateway for locally originated DMR traffic. Existing installations retain the legacy D-APRS path unless the native DATA_GATEWAY setting and relationship are enabled.

The installer requests the APRS-IS login and passcode and writes the matching worker relationships. The gateway remains a separate container and is not a fallback when its native links are unavailable.

The separately downloadable upgrade-daprs-to-data-gateway.sh helper can migrate the documented legacy D-APRS Compose service while preserving and backing up the surrounding FreeDMR configuration.

Other operator-visible changes

  • Network direct dial is available and defaults to local TG9 on TS1. Set NETWORK_DIRECT_DIAL_SLOT: 0, or session option NDD_SLOT=0, to disable it.
  • Dial-a-TG control, defaults and timers can be configured independently for TS1 and TS2. Existing TS2 option aliases remain supported.
  • DIAL_A_TG and DYNAMIC_TG_ROUTING can disable their respective dynamic routing behaviours.
  • HBP OPTIONS input is bounded to 255 bytes. Oversized values are acknowledged but ignored.
  • Optional DMR data observability is available through DATA_PACKET_LOGGING. It is disabled by default because decoded logs may contain message or location content.
  • Reporting includes source server and repeater metadata without changing the existing leading report fields.
  • The shipped ALLOW_UNREG_ID default is now True for established FreeDMR access compatibility.
  • The installer uses the current Docker repository setup on Debian 12.

Compatibility

FBP v5 and OBP v1 remain distinct supported peer protocols. The HDStack internal topology uses FBP v5/FBCP and consumes one additional FBP hop. The accepted maximum is 20 hops for all FBP relationships.

The tagged container build publishes latest, the tag-specific v1.5.0-with-proxy image and development-latest through the existing release pipeline.

Powered by TurnKey Linux.