v0.51.0

Nodes upgrade independently: nothing on the air changes. Existing installs keep their settings. A brand new install now needs an app token before apps can use MQTT or REST.

The first start after upgrading builds some new database indexes. On a Pi with a long message history that can take a minute or more, once.

What you will notice

MCP is gone (#308, #344). The /mcp endpoint was unauthenticated and could change settings, transmit and read every message, and nothing was using it. It has been removed entirely rather than secured. It may come back later, behind proper authentication.

New installs require app tokens, and there is a page to make them (#316, #343). On a fresh install, MQTT and REST apps need a per-app token from the start. The new Tokens page on the dashboard creates a token for an app (shown once, with a copy button), lists the apps that have one, and revokes them. Revoking or replacing a token stops REST at once and drops the app's open MQTT connections. Existing installs keep whatever they had. The install docs now say plainly that the dashboard listens on every interface with no password until Setup is finished, and that the MQTT broker listens on every interface; bind to localhost or firewall them on an untrusted network.

A relay no longer floods (#295, #345). Over packet links, a node with no route for a message passing through used to start a fresh flood to every neighbour, including the one it came from, so one message could reach every node in the network. Now only the node that sent a message floods it. A relay with no route keeps it queued until a route turns up or it expires. A message is never sent back to the neighbour it came from, including a neighbour that calls through BPQ with its SSID inverted.

Saving settings no longer drops your links (#273, #346). Any save, including the TX STOP and RESUME buttons, used to close the connection to BPQ or XRouter, which dropped every live session on air. Now only a change to the bearer, callsign, node host, port or RHP login reconnects.

Also

• Forwarded and delivered messages are deleted 30 days after they finished, and drop records after 90 days, so the database and the dashboard stay quick (#286, #348).
• A repeated message id in the dropped list could stop the forwarder sending anything ever again, or wedge a neighbour's link at one message. Fixed, and delivered mail no longer shows as "ttl-expired" on the Dropped tab (#284, #285, #342).
• One malicious offer could make the node allocate about 2 GB. Message lengths are now capped at 16 MB per hop before anything is allocated (#262, #341).
• AGW: frame lengths are checked before allocating, one bad frame no longer drops every session, a dial can no longer hang the forwarder for ever, and a node with two AGW discovery ports hears beacons again (#274, #276, #278, #349).
• MQTT: an app can only publish under dapps/ to its own out and ack topics, so nobody can fake heartbeat or audit messages. An ack only marks the acking app's own messages; before, any app could stop another app's mail being forwarded. Reconnecting with the same client id keeps its auth. Refusals answer NotAuthorized on MQTT 5 (#291, #310, #311, #312, #350).
• Apps on the same node can still read each other's MQTT traffic. That is by design.

For app developers

• An app that acks a message that is not its own now gets 404 on REST, or NotAuthorized on MQTT 5.
• App names are lowercased and must be plain ASCII without /, +, # or spaces.

Known issues

• The optional meshcore routing algorithm still floods at relays and does not learn paths (#295, #296). The default routing is not affected.
• Route gossip can still advertise a route back to the neighbour it came from (#297). Mail caught by that now waits at the far node instead of being lost.

v0.50.0

Nodes upgrade independently, and operators change no configuration. One new line on the air, ping, which older nodes ignore.

What you will notice

Probe always gives an answer (#260, #261). When DAPPS already had a session open with the peer, a probe used to refuse to dial, because a second call resets the link. So it said nothing at exactly the moment you most wanted to know why traffic had stopped. Now it sends a ping down the open session and waits up to a minute for the pong. You get the round trip, or "no answer", along with:

• who called whom, and how long the session has been up
• when the peer was last heard from
• how many of your messages are waiting for an answer, and how long the oldest has waited

That tells apart a link that works, one that is up at your node but gets nothing through (a ping that goes unanswered until the session gives up), and a peer on an older DAPPS that doesn't answer pings.

If DAPPS has the peer marked as in a session but has nothing running to ask, the probe says which way and for how long. After 5 minutes it says it looks stuck; restarting DAPPS clears that.

On the dashboard the answer appears in a pop-up after probe or probe now. Over MCP, run_probe returns it as Detail; POST /Probes/run/{callsign} returns it as detail.

Also

• Pings never count as progress, so probing can't keep open a session whose messages go unanswered. Like any traffic, they do restart an idle session's quiet spell.
• Scheduled probe sweeps take the same path, so a sweep that meets an open session pings it instead of recording a failure.

Known issues

• A peer before 0.50.0 never answers a ping, so a probe of an open session with one reports no answer. The message says so when the peer is still sending.

v0.49.0

No wire change: nodes upgrade independently, and operators change no configuration. This release also carries 0.47.3, 0.48.0 and 0.48.1, which were never published.

What you will notice

Dashboard help text rewritten (#256). Every field has a one-line hint, every panel a one-sentence intro, and the two things that need a paragraph, connect scripts and discovery channels, sit behind a "How this works" toggle that links to the manual. The connect-script box now says what a step is (the command, a |, then the text to wait for) with an example, and when a script is needed at all.

Setup wizard fix. On a fresh install the Node bearer and RHPv2 password labels printed their own source, BEARER@IF (SETUPMODEL.ISENVMANAGED(...)). Razor reads word@if as an email address. Fixed.

Discovery channels can be managed from the dashboard (#258). The form takes a beacon cadence in minutes (blank keeps the link class default) and an Enabled box; each row has edit and enable/disable. The Class column shows the class name instead of a number.

Discovery follows changes without a restart. The beacon loop used to read the channel table once at start, so disabling a channel on the dashboard did not stop it beaconing until DAPPS was restarted. It now re-reads the table every 10 seconds. The same reload now owns the bearers: if the packet node is down when DAPPS starts, or drops later, discovery retries it (10 s three times, then 30 s, 60 s, then every 5 minutes) instead of giving up for good, and a channel added on a new bearer or a new UDP multicast group starts without a restart.

Settings shows the Overnight hours only under the Overnight strategy and the quiet window only under When quiet. Saving no longer resets the settings the page does not show (0.48.1).

Quick send expires after 24 hours, the same as Compose's default.

Apps read who a message is from in dapps-source (MQTT) or sourceCallsign (REST); both used to carry the last hop, which now lives in dapps-via and viaCallsign (0.48.0). Apps that read dapps-source to mean the last hop should read dapps-via.

Probing stops trying a two-hop candidate that has never answered after 3 tries, and a probe by hand works for a candidate (0.47.3).

Also

• Three places said the forwarder ticks every 5 s; it runs as soon as a message is queued, or within 30 s.
• Plan labels (B6.1, F3b, "model C") are gone from the UI; "Admin password", "Link hold" and "Settings" are named the same everywhere.
• The Overview's "Audit log" button is now "Diagnostics", the page it opens.
• RouteGossipStalenessHours is now actually loaded and saved; 0 turns gossip pulls off (0.48.1).

Known issues

• A discovery channel added from the dashboard takes the link class defaults for advertised TTL and cost; change those through POST /DiscoveryChannels.
• Learned routes and route hints are still visible only through the MCP tools.

v0.47.2

XRouter's web dashboard keeps working after you log in to DAPPS

On a node running both, logging in to the DAPPS dashboard made the XRouter web dashboard answer "HTTP error 400 - Bad Request" (or drop the connection on XRouter 505c) until you cleared the browser's cookies (#248).

Browsers send a host's cookies to every port on that host, so XRouter was receiving DAPPS's cookies too, and together they were just over the longest header line XRouter accepts. DAPPS's cookies are now about a sixth smaller and well under that limit:

• Cookies are sealed with AES-256-GCM instead of AES-CBC + HMAC. That is the same strength or better, with less overhead.
• The antiforgery cookie is now called dapps.af, and the old long-named one is removed.

You stay logged in across the upgrade. Your next page load swaps in the smaller cookies, and XRouter's dashboard works again without clearing anything. XRouter's limit is reported upstream as packethacking/xrouter-container#30.

Probe candidates use the right port

Also in this release (it was numbered 0.47.1 on master but never published on its own): a station learned from a neighbour's peers list was probed on the neighbour's port number instead of our own port to that neighbour. On XRouter every such probe failed with "RHP error 10: Invalid port". Candidates now use the port their neighbour answered on, and ones already stored with the wrong port are corrected (#246).

Upgrading

• Nodes upgrade independently. Nothing changes on the air, and there is nothing to configure.
• The first start after upgrading writes one new data protection key next to the existing ones.

Known issues

• Other web apps on the same host can still push XRouter's dashboard over its limit with their own cookies. To keep them apart, open DAPPS and XRouter under different host names (for example, one by IP address and one by name).

v0.47.0

Two nodes under one callsign now work

DAPPS treats the SSID as part of a node's identity everywhere, as the docs always said. G6FCI-7 and G6FCI-8 are two stations, not one.

• Messages between two SSIDs of one callsign are delivered. Before, a node took mail for another SSID of its own callsign as its own: it sat in its local inbox as "awaiting ack" and never left (#239).
• Routing keeps one route per callsign and SSID. The routes exchange between nodes now carries the full callsign, and learned routes and discovered paths are stored per station. Two SSIDs of one callsign behind a relay can now reach each other (#242).
• The Neighbours panel marks a neighbour that may have the wrong SSID ("SSID?").

Upgrading

• Every node should upgrade. Mixed versions still exchange mail. Routing only improves once both ends have upgraded, and in the meantime routes from a node that hasn't upgraded stop covering stations with an SSID.
• No configuration changes. Neighbours and route hints work as they are. A route hint with no SSID still covers every SSID of that callsign. A hint written with an SSID, which never matched anything before, now routes that station.
• Learned routes start afresh after the upgrade and relearn on their own. Downgrading to 0.46 is safe; routes simply relearn again.
• A neighbour entered without its SSID still works locally, but is now advertised to other nodes as SSID 0. Correct the SSID if the panel marks it.

Known issues

• BPQ changes the SSID of a call made through it to 15 minus the SSID, so G6FCI-8 arrives as G6FCI-7. If you run two DAPPS SSIDs of one callsign and calls pass through BPQ nodes, avoid SSID pairs that add up to 15.
• Route gossip from older nodes covers SSID 0 only until they upgrade.

v0.46.2

DAPPS 0.46.2

The .deb now installs on Ubuntu 26.04. Before, apt refused it with "none of the choices are installable" because the package named ICU only up to libicu76, and 26.04 ships libicu78 (#232, thanks Chris for the report).

• The package accepts ICU from libicu63 up to libicu80, so the next distro releases should install without waiting for a DAPPS release.
• CI now installs the package on clean Debian 12, Debian 13, Ubuntu 22.04, 24.04 and 26.04 and checks the daemon starts on each.

No code change and no wire change. Nodes that already installed fine don't need to upgrade.

Full changes: v0.46.1...v0.46.2

v0.46.1

A small fix for DAPPS on the packet.net node (pdn), plus more thorough release testing.

Upgrading: no wire changes. 0.46.1 works alongside any 0.42 or later node.

Fixed

pdn's "Already connected" is now understood. Recent pdn versions refuse a call when something at the node already holds the link to that station. DAPPS logged that as a failed send and counted it against the neighbour, though the message usually still went on the open session moments later.

• Usually it means the two nodes called each other at the same moment. DAPPS now treats it as a crossed call, with nothing counted as failed, and sends the message on the session the other node's call opened.
• If no call from the other node arrives within 5 seconds, something else holds the link, such as a sysop's console session or another app. That's an ordinary failed call with the usual cooldown, and the log now says the link is held elsewhere.

Under the hood

• More thorough release testing: every release is now tested on simulated radio channels, Kevin M0AHN's WPS trace and calls crossing, on both BPQ and pdn, before it ships.
• Pinned test images: the tests now pin XRouter to a known image. One published after 10 October stopped answering DAPPS's AGW connection check (#231 is looking into why).

Full changelog: v0.46.0...v0.46.1

v0.46.0

What's Changed

• 0.46.0: on an apt install, check the apt repository and show the upgrade command by @M0LTE in #228

Full Changelog: v0.45.2...v0.46.0

v0.45.2

What's Changed

• Docs: a direct connect to a DAPPS callsign doesn't reach DAPPS on every node by @M0LTE in #226
• 0.45.2: lay out the neighbour form in aligned columns by @M0LTE in #227

Full Changelog: v0.45.1...v0.45.2

v0.45.1

What's Changed

• Docs: a connect script ends on a connect to the DAPPS callsign by @M0LTE in #224
• 0.45.1: a link still closing defers the message; log each RHPv2 link by @M0LTE in #225

Full Changelog: v0.45.0...v0.45.1