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=1explicitly to retain the established single-process layout. - Set
HDSTACK_BASEIDto the aggregator server ID. Workers use successive IDs beginning atHDSTACK_BASEID + 1. - The read-only FreeDMR container requires a writable
/tmp. The shipped Compose file provides this withtmpfs: /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
OPTIONSstate. - 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.pyprocess is disabled by default. SetHDSTACK_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 optionNDD_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_TGandDYNAMIC_TG_ROUTINGcan disable their respective dynamic routing behaviours.- HBP
OPTIONSinput 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_IDdefault is nowTruefor 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.