From 03bdd02fd17cf31762ef3c7308e0e9b188ab51a6 Mon Sep 17 00:00:00 2001 From: Tom M0LTE <37816024+M0LTE@users.noreply.github.com> Date: Thu, 11 Jun 2026 01:32:57 +0100 Subject: [PATCH] docs: BPQ APPLICATION line needs the DAPPS callsign in APPLCALL The docs rewrite in d174cbe dropped the APPLCALL field from the documented APPLICATION line (APPLICATION 1,DAPPS,,,,, 0). Verified in a two-node linbpq lab: with that shape, BPQ ignores inbound L2 connects to the AGW-registered DAPPS callsign entirely (callers see RETRYOUT) - the runtime 'X' registration tells BPQ which AGW client gets the session, but only the APPLCALL declaration makes BPQ accept the connect at all. Restoring the full form fixes node-to-node probes both ways. Also documents two failure signatures hit while reproducing a field report (Kevin M0AHN): UA-then-silence when a neighbour row points at the remote NODECALL instead of its DAPPS callsign, and the need for an AXIP/AXUDP MAP entry covering the remote DAPPS callsign. Co-Authored-By: Claude Fable 5 --- docs/connect/bpq.md | 23 +++++++++++++++++++---- docs/getting-started.md | 6 +++--- docs/troubleshooting.md | 9 +++++---- 3 files changed, 27 insertions(+), 11 deletions(-) diff --git a/docs/connect/bpq.md b/docs/connect/bpq.md index 5ce5f40..cdddb41 100644 --- a/docs/connect/bpq.md +++ b/docs/connect/bpq.md @@ -10,21 +10,25 @@ This is one TCP connection from DAPPS to BPQ (not co-located requirements; DAPPS ## Step 1: configure BPQ -Add an `APPLICATION` line to your `bpq32.cfg`: +Add an `APPLICATION` line to your `bpq32.cfg`, carrying the DAPPS callsign (the call+SSID you'll give DAPPS in step 3) in the APPLCALL field: ``` -APPLICATION 1,DAPPS,,,,, 0 +APPLICATION 1,DAPPS,,M0LTE-7,DAPPS,0 ``` Field-by-field: - `1` - application slot number. Bump this if slot 1 is already in use; the value doesn't matter beyond uniqueness. - `DAPPS` - the command operators type at the BPQ node prompt to enter the DAPPS slot. If you'd rather use a different name (`MSG`, `APPS`, whatever), put it here and update **Node-prompt application command** under the dashboard's **Edit configuration** to match. -- `,,,,,` - empty CMD field on purpose. Older recipes used `C N HOST K TRANS S` here; for DAPPS, leave it empty so BPQ doesn't run any node command on inbound - it just dispatches the L2 'C' frame to the registered AGW client. -- `0` - application alias / number flag. +- (empty third field) - the CMD field, empty on purpose. Older recipes used `C N HOST K TRANS S` here; for DAPPS, leave it empty so BPQ doesn't run any node command on inbound - it just dispatches the L2 'C' frame to the registered AGW client. +- `M0LTE-7` - the **APPLCALL**: the DAPPS callsign. This is the field that makes BPQ accept inbound L2 connects addressed to the DAPPS callsign. DAPPS registering the same callsign over AGW at runtime tells BPQ *which AGW client* gets those sessions; the APPLCALL declaration is what makes BPQ accept them at all. Without it, BPQ ignores connects to the DAPPS callsign and the remote caller times out with RETRYOUT. +- `DAPPS` - the APPLALIAS. Lets stations connect to the alias as well as the callsign. +- `0` - quality. Zero keeps the application callsign out of NODES broadcasts; raise it only if you want the DAPPS call advertised as a node. Restart BPQ for the change to land. +The division of labour is worth spelling out, because it trips people up: an inbound connect to the **DAPPS callsign** (`M0LTE-7` above) goes straight to DAPPS and never sees the node menu; an inbound connect to your **node call** lands at the node menu, where typing `DAPPS` enters the application. Both paths end at the same place; the APPLCALL route is the one DAPPS itself uses for node-to-node sessions. + You can also enable AXIP / AXUDP / serial ports as you would for any application - DAPPS doesn't care which physical link AGW is fronting, as long as BPQ delivers sessions over the AGW socket. ## Step 2: confirm AGW is reachable from where DAPPS will run @@ -92,6 +96,17 @@ If your BPQ has multiple radio ports (e.g. port 1 = VHF FM, port 2 = HF), every You don't need an `APPLICATION` line per port - the single `APPLICATION DAPPS` line covers all ports. The port choice is per-neighbour for outbound; for inbound, BPQ dispatches the same way no matter which port the connect arrived on. +## AXIP / AXUDP links + +If the port a neighbour is reached over is an AXIP/AXUDP port with per-callsign `MAP` entries (common for LAN or internet links between two BPQ nodes), remember that the L2 connect DAPPS originates is addressed to the remote **DAPPS callsign**, not the remote node call. Add a `MAP` for the DAPPS callsign alongside the node call: + +``` +MAP MB7XXX 192.168.1.20 UDP 10093 B +MAP M0XYZ-7 192.168.1.20 UDP 10093 B +``` + +Without the second entry, the SABM to the DAPPS callsign has nowhere to go and the connect retries out on the *originating* side. + ## Sharing a callsign between BPQ and DAPPS The recommended pattern is to give DAPPS its own SSID under your callsign - `M0LTE-1` for the BBS, `M0LTE-7` for DAPPS, etc. AGW dispatches by exact call+SSID, so they coexist cleanly. You can run as many DAPPS instances against one BPQ as you have spare SSIDs. diff --git a/docs/getting-started.md b/docs/getting-started.md index d8b32c2..4ea39bf 100644 --- a/docs/getting-started.md +++ b/docs/getting-started.md @@ -59,13 +59,13 @@ Submit; the daemon picks up the new callsign and bearer within a few seconds (no The DAPPS side is now configured; your packet node needs to know to dispatch sessions to DAPPS. This is the part that depends on your node software. -**For BPQ**, add an `APPLICATION` line to `bpq32.cfg`: +**For BPQ**, add an `APPLICATION` line to `bpq32.cfg`, with your DAPPS callsign (the one from step 2, not your node call) in the APPLCALL field: ``` -APPLICATION 1,DAPPS,,,,, 0 +APPLICATION 1,DAPPS,,M0LTE-7,DAPPS,0 ``` -This advertises a `DAPPS` command at the BPQ node prompt and routes inbound L2 connects over AGW. Restart BPQ to pick it up. The [BPQ connect page](connect/bpq.md) has the full recipe. +This advertises a `DAPPS` command at the BPQ node prompt, and - via the APPLCALL field - tells BPQ to accept inbound L2 connects to the DAPPS callsign and dispatch them over AGW. The APPLCALL is not optional: DAPPS registering the callsign over AGW at runtime is not enough on its own, and without the APPLCALL BPQ ignores inbound connects to the DAPPS callsign entirely (remote callers see RETRYOUT). Restart BPQ to pick it up. The [BPQ connect page](connect/bpq.md) has the full recipe. **For XRouter**, add `RHPPORT=9000` to `XROUTER.CFG` and restart XRouter. No `APPL` block is needed - DAPPS binds the callsign over RHPv2 dynamically. The [XRouter connect page](connect/xrouter.md) has the details. diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md index 59198da..629c876 100644 --- a/docs/troubleshooting.md +++ b/docs/troubleshooting.md @@ -54,9 +54,9 @@ DAPPS reconnects automatically (with backoff). If it's flapping every few second A remote node can `c ` and lands at the BPQ node prompt, but not at the `DAPPSv1>` prompt. Check: -- The `APPLICATION 1,DAPPS,,,,, 0` line is in `bpq32.cfg` and BPQ has been restarted since adding it. -- The CMD field on the `APPLICATION` line is **empty** (the `,,,,,`). Older recipes had `C N HOST K TRANS S` here - for DAPPS, leave it empty so BPQ doesn't run a node command on inbound, just dispatches the L2 'C' frame to the registered AGW client. -- DAPPS is registering the right callsign. The startup log shows `AGW: registered for inbound dispatch`. If the callsign there doesn't match what the remote is connecting to, it won't route. +- The `APPLICATION` line is in `bpq32.cfg` with the DAPPS callsign in the **APPLCALL** field - `APPLICATION 1,DAPPS,,M0LTE-7,DAPPS,0` - and BPQ has been restarted since adding it. The runtime AGW registration alone is **not** enough on BPQ: without the APPLCALL, BPQ ignores inbound connects to the DAPPS callsign entirely and the remote caller sees RETRYOUT. +- The CMD field on the `APPLICATION` line (the third field) is **empty**. Older recipes had `C N HOST K TRANS S` here - for DAPPS, leave it empty so BPQ doesn't run a node command on inbound, just dispatches the L2 'C' frame to the registered AGW client. +- DAPPS is registering the right callsign. The startup log shows `AGW: registered for inbound dispatch`. If the callsign there doesn't match what the remote is connecting to (and the APPLCALL), it won't route. - AGW exact-match is by call+SSID. `M0LTE-1` is different from `M0LTE-7`. ### Inbound sessions never arrive (XRouter RHPv2) @@ -89,7 +89,8 @@ Check, in order: The probed-nodes table shows the recent failure reason. Common ones: -- **`RETRYOUT`**: the bearer retried the connect to the remote callsign but never got a response. The remote isn't reachable on the link, or the bearer port for that peer is wrong (per-neighbour `BearerPort` or `DAPPS_DEFAULT_BEARER_PORT`). +- **`RETRYOUT`**: the bearer retried the connect to the remote callsign but never got a response. Three common causes: the remote isn't reachable on the link; the bearer port for that peer is wrong (per-neighbour `BearerPort` or `DAPPS_DEFAULT_BEARER_PORT`); or the remote BPQ doesn't declare the DAPPS callsign in an `APPLICATION` line's APPLCALL field - in that case BPQ silently ignores connects to the callsign even though the remote DAPPS registered it over AGW. +- **Connect accepted (UA) but then silence, ending in `timeout: ... no data from peer`**: the classic signature of probing the remote's **node call** instead of its DAPPS callsign. The node accepts the L2 connect and then sits at its (silent) command prompt waiting for input, while the probe waits for a `DAPPSv1>` banner that will never come. Check the neighbour row's callsign is the remote *DAPPS* callsign (e.g. `M0XYZ-7`), not the NODECALL. - **Connect timeout**: the connect went out but the protocol parser never saw the `DAPPSv1>` prompt. The peer either isn't running DAPPS, or you're connecting to the wrong application (their `APPLICATION` line might use a different command name). - **TIMEOUT after `DAPPSv1>`**: probe got the prompt but the session hung. Network is dropping packets mid-session, or one side has a serious clock skew.