# Unwanted reorder or fast busy tone **URL:** \ **Category:** AllStarLink\ **Created:** [August 24, 2026, 3:41am UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944 "2026-08-24T03:41:06Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![K6MBY](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/32/5022_2.png) [@K6MBY](https://community.allstarlink.org/u/K6MBY)\ **Post date:** [August 24, 2026, 3:41am UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/1 "2026-08-24T03:41:06Z")
**Subject: Rhythmic ~2Hz "fast busy/reorder"-style tone injected into audio bridge only when linktolink duplex=0 link is established — persists across two different RIM devices, all gain/duplex settings, unrelated to downstream hardware** **Setup:** - ASL3, Raspberry Pi - Node 1998: `Voter/1998` — receiver-voting node (BridgeCom BCR + MT500 RTCM clients), `duplex = 2` - Node 1996: `SimpleUSB/usb_1996` — USB RIM interfacing into an Arcom RC210 port, `duplex = 0` in rpt.conf, `linktolink = yes` (the documented special case for interfacing with an external multiport controller) - Linked via: `rpt cmd 1998 ilink 3 1996` (transceive) **Symptom:** A rhythmic tone — described by ear as sounding like a telco fast-busy/reorder signal — begins the moment the 1998↔1996 link is established and continues indefinitely (only clears on a full `systemctl restart asterisk`). Specifics: - Absent when node 1996 is up standalone, before the link to 1998 is made — only appears once bridged - Rides on top of real, clean receive audio (tested with a calibrated RTCM, 1kHz tone at 3kHz deviation, CTCSS present) — both are audible simultaneously, unaffected by each other - Identical behavior across two different physical USB RIM devices (a generic CM108-based unit and a Masters Communications RA-33) - `RPT_TXKEYED` on both nodes shows a constant `1` throughout — never flaps — consistent with the documented "Special Case: Full duplex if linktolink is set to yes" behavior, so this isn't a PTT/key-state toggle - Unaffected by: `txmixaset` (tested 200–900), USB port, physical distance from RF sources, `duplex` in rpt.conf's [1996] stanza (tested 0 and 2), `duplex` in simpleusb.conf's [usb\_1996] stanza (tested 0 and 1, inherited from [node-main]), `propagate_dtmf` (tested yes/commented out on both nodes), `carrierfrom`/`ctcssfrom` (tested no and usbinvert) - Zero corresponding entries in `/var/log/asterisk/messages.log` at NOTICE/WARNING level correlating with the tone's timing, even with continuous `tail -f` capture through multiple full cycling episodes - A separate, unrelated RC210-side issue (Port 1's "Repeater Mode" checkbox) was found and fixed during this troubleshooting — confirmed not the cause, since disabling it did not stop the tone **Config excerpts (rpt.conf, simpleusb.conf, modules.conf) available on request — happy to post directly or via pastebin.** **Question:** Given the tone only appears once bridged (never standalone), persists regardless of hardware/gain/duplex settings on both sides, and sounds like Asterisk's own Congestion()/reorder indication — is this a known interaction between chan\_voter's mix-mode client protocol and the linktolink=yes/duplex=0 softmix bridge? Is there a way to get debug-level tracing on the actual bridge/dial leg between these two channels that would surface in the log? Happy to provide a debug-level capture, full config files, or test anything else on request. ---
**Author:** ![N8RAW](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8raw/32/2906_2.png) [@N8RAW](https://community.allstarlink.org/u/N8RAW)\ **Post date:** [August 24, 2026, 1:26pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/2 "2026-08-24T13:26:46Z")
We added a fix for this in the latest build. Please ping us if 3.10.x does not address it (when it's released, or if you want to try beta, let us know sooner 🙂 ) ---
**Author:** ![K6MBY](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/32/5022_2.png) [@K6MBY](https://community.allstarlink.org/u/K6MBY)\ **Post date:** [August 24, 2026, 3:23pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/3 "2026-08-24T15:23:59Z")
This is not a working system at the moment so I would try the beta. Thanks. Bob K6MBY ---
**Author:** ![K6MBY](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/32/5022_2.png) [@K6MBY](https://community.allstarlink.org/u/K6MBY)\ **Post date:** [August 25, 2026, 12:31pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/4 "2026-08-25T12:31:02Z")
Installed v 3.10.4-1. Confirmed with $ apt-cache policy asl3-asterisk asl3-asterisk: Installed: 2:22.10.1+asl3-3.10.4-1.deb13 Candidate: 2:22.10.1+asl3-3.10.4-1.deb13 Version table: **Update: tested on the new beta release — cycling tone still present, unchanged.** Same reproduction steps as my original report: link established (`rpt cmd 1998 ilink 3 1996`), tone begins immediately, persists until a full Asterisk restart. No change in behavior, character, or timing that I could detect. Bob K6MBY ---
**Author:** ![K6MBY](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/32/5022_2.png) [@K6MBY](https://community.allstarlink.org/u/K6MBY)\ **Post date:** [August 25, 2026, 6:15pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/5 "2026-08-25T18:15:05Z")
First, I am not this smart. I am using Claude.ai to help diagnose this issue. **Update: confirmed via spectral analysis — this IS Asterisk's Congestion()/fast-busy indication tone** I recorded the cycling audio using app\_rpt's `archivedir` feature (recording on node 1998) and ran a spectral analysis on the capture. Results: - **Rhythmic bursts every ~0.5 seconds** , consistent throughout a 195-second recording (354 onset events) - **Dominant frequencies: 480 Hz and 620 Hz** — this is the exact standard North American telco "fast busy"/reorder tone pair, matching Asterisk's own `Congestion()` indication as defined in `indications.conf` So this isn't a hardware artifact, USB noise, or coincidental buzz — Asterisk is genuinely generating and injecting its own Congestion tone into the audio stream repeatedly while the link is up. **Also worth noting:** - The tone is **not 100% reproducible on every single `rpt cmd 1998 ilink 3 1996` attempt** — most attempts trigger it, but occasionally a link comes up clean with no tone at all. This may point to a timing/race condition rather than a purely deterministic config interaction. - Confirmed present on: two different physical USB RIM devices, a beta ASL3 release, and a completely fresh SD card flash of the current stable release with configs restored from a known-good backup — rules out hardware, package-version, and install-state causes. - IAX2 debug logging during a confirmed cycling episode shows completely normal control-plane traffic (standard LAGRQ/LAGRP/PING/PONG cadence, zero retries/errors) — the tone isn't an IAX2 transport issue, it's being generated as actual audio content somewhere in the bridge/channel logic. Given the tone is specifically `Congestion()`/reorder — normally played when a call setup or dial attempt fails — this suggests something in the `linktolink=yes`/`duplex=0` bridge path between a Voter channel and a SimpleUSB channel is intermittently hitting a failure/retry condition internally and signaling it audibly, even though the link itself (per `rpt lstats`) shows as ESTABLISHED and stable the whole time. Bob K6MBY ---
**Author:** ![WA3WCO](https://community.allstarlink.org/user_avatar/community.allstarlink.org/wa3wco/32/3123_2.png) [@WA3WCO](https://community.allstarlink.org/u/WA3WCO)\ **Post date:** [August 25, 2026, 7:01pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/6 "2026-08-25T19:01:04Z")
Q? have you made ANY changes to your `/etc/asterisk/extensions.conf` file? Note: an unmodified copy of the file can be found @ `/usr/share/doc/asl3-asterisk-config/examples/configs/asl3/extensions.conf`) ---
**Author:** ![K6MBY](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/32/5022_2.png) [@K6MBY](https://community.allstarlink.org/u/K6MBY)\ **Post date:** [August 25, 2026, 8:21pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/7 "2026-08-25T20:21:59Z")
Confirmed — ran `diff` against the unmodified copy at `/usr/share/doc/asl3-asterisk-config/examples/configs/asl3/extensions.conf` and there are no differences at all. My `/etc/asterisk/extensions.conf` is stock, unmodified. ---
**Author:** ![N8RAW](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8raw/32/2906_2.png) [@N8RAW](https://community.allstarlink.org/u/N8RAW)\ **Post date:** [August 26, 2026, 12:22pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/8 "2026-08-26T12:22:42Z")
OK, doing some digging. Not sure "why" this changed at the moment. It's one of those head scratchers. ---
**Author:** ![W5GLE](https://community.allstarlink.org/user_avatar/community.allstarlink.org/w5gle/32/4480_2.png) [@W5GLE](https://community.allstarlink.org/u/W5GLE)\ **Post date:** [August 26, 2026, 12:37pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/9 "2026-08-26T12:37:44Z")
During an active tone episode: core show channels verbose — look for a channel with an active generator bridge show all — which member is feeding TX conf Provide the following and it will make this easier to debug. ---
**Author:** ![K6MBY](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/32/5022_2.png) [@K6MBY](https://community.allstarlink.org/u/K6MBY)\ **Post date:** [August 26, 2026, 2:27pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/10 "2026-08-26T14:27:56Z")
Worth noting on timing: this started specifically when I was testing `propagate_dtmf = yes` while sending real DTMF tones through an RTCM into the voter node — not just from adding the config line itself (I later tested with `propagate_dtmf` commented out again, and the cycling persisted regardless). So it may be tied to something about a DTMF sequence being decoded/processed at that time, even though it's not required to reproduce it afterward. One detail that might matter: my `rpt.conf` function table has the autopatch codes (`61`/`62` → `autopatchup`/`autopatchdn`) commented out/disabled — so I wouldn't expect a DTMF sequence to be able to trigger a real autopatch request through normal function-code handling. That makes the stuck `Local/Autopatch@default` channel in `Ring` state (from the `core show channels verbose` output) more puzzling — not sure what's actually opening it if autopatch isn't enabled. sudo asterisk -rx "core show channels verbose" sudo asterisk -rx "bridge show all" Channel Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccoun t BridgeID Recorder/PChan-00000000;2 default s 1 Up (None) (Empty) 00:00:18 b7e2e667-c674-452c-b Recorder/PChan-00000000;1 default s 1 Up (None) (Empty) 00:00:18 SimpleUSB/usb\_1996 default 1 Up Rpt Repeater Rx 00:00:18 Recorder/MonChan-00000002;1 default s 1 Up (None) (Empty) 00:00:18 Recorder/MonChan-00000002;2 default s 1 Up (None) (Empty) 00:00:18 ae7f7b44-a45f-4376-a Announcer/IAXLink-0000000e;1 default s 1 Up (None) (Empty) 00:00:11 Announcer/IAXLink-0000000e;2 default s 1 Up (None) (Empty) 00:00:11 003149f4-4d0e-4ca5-b Local/LocalTX@default-00000005;2 default LocalTX 1 Up (None) (Empty) 00:00:18 7ad6d844-481a-426e-b Local/LocalTX@default-00000005;1 default LocalTX 1 Up (None) (Empty) 00:00:18 Recorder/MonChan-00000006;1 default s 1 Up (None) (Empty) 00:00:18 Recorder/MonChan-00000006;2 default s 1 Up (None) (Empty) 00:00:18 7ad6d844-481a-426e-b Announcer/Telemetry-0000000f;1 default s 1 Up (None) (Empty) 00:00:09 Announcer/Telemetry-0000000f;2 default s 1 Up (None) (Empty) 00:00:09 ae7f7b44-a45f-4376-a Announcer/TXPChan-00000008;1 default s 1 Up (None) (Empty) 00:00:18 Announcer/TXPChan-00000009;1 default s 1 Up (None) (Empty) 00:00:18 Announcer/TXPChan-00000008;2 default s 1 Up (None) (Empty) 00:00:18 ae7f7b44-a45f-4376-a Announcer/TXPChan-00000009;2 default s 1 Up (None) (Empty) 00:00:18 7ad6d844-481a-426e-b Local/LocalTX@default-00000001;2 default LocalTX 1 Up (None) (Empty) 00:00:18 ae7f7b44-a45f-4376-a Local/LocalTX@default-00000001;1 default LocalTX 1 Up (None) (Empty) 00:00:18 Announcer/RXPChan-00000007;1 default s 1 Up (None) (Empty) 00:00:18 Announcer/RXPChan-00000007;2 default s 1 Up (None) (Empty) 00:00:18 003149f4-4d0e-4ca5-b Announcer/IAXLink-0000000c;2 default s 1 Up (None) (Empty) 00:00:11 b7e2e667-c674-452c-b Announcer/IAXLink-0000000c;1 default s 1 Up (None) (Empty) 00:00:11 IAX2/127.0.0.1:4569-13724 radio-secure 1996 14 Up Rpt 1996 1998 00:00:11 Announcer/RXPChan-00000003;1 default s 1 Up (None) (Empty) 00:00:18 Announcer/RXPChan-00000003;2 default s 1 Up (None) (Empty) 00:00:18 b7e2e667-c674-452c-b Local/Autopatch@default-0000000a;2 default Autopatch 1 Ring (None) (Empty) 00:00:16 Local/Autopatch@default-0000000a;1 default Autopatch 1 Down (None) (Empty) 00:00:16 IAX2/127.0.0.1:4569-78 1996 1 Up Rpt Remote Rx 00:00:11 Recorder/PChan-00000004;2 default s 1 Up (None) (Empty) 00:00:18 003149f4-4d0e-4ca5-b Recorder/PChan-00000004;1 default s 1 Up (None) (Empty) 00:00:18 voter/1998 default 1 Up Rpt Repeater Rx 00:00:18 Local/GenChannel@default-0000000b;2 default GenChanne l 1 Up (None) (Empty) 00:00:16 b7e2e667-c674-452c-b Local/GenChannel@default-0000000b;1 default GenChanne l 1 Up (None) (Empty) 00:00:16 34 active channels 1 active call 1 call processed Bridge-ID Name Chans Type Technology Dur ation 003149f4-4d0e-4ca5-bd04-d4d5dfe1c07e CONF 3 base softmix 00: 00:19 7ad6d844-481a-426e-b99c-7dce910e172d TXCONF 3 base softmix 00: 00:19 ae7f7b44-a45f-4376-a96c-42b3a243232f TXCONF 4 base softmix 00: 00:19 b7e2e667-c674-452c-b08d-9d252bee23e1 CONF 4 base softmix 00: 00:19 ---
**Author:** ![N8RAW](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8raw/32/2906_2.png) [@N8RAW](https://community.allstarlink.org/u/N8RAW)\ **Post date:** [August 26, 2026, 3:03pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/11 "2026-08-26T15:03:36Z")
> [@K6MBY](#): > > Local/GenChannel@default-0000000b;2 default GenChanne l 1 Up (None) (Empty) 00:00:16 b7e2e667-c674-452c-b > Local/GenChannel@default-0000000b;1 default GenChanne l 1 Up (None) (Empty) 00:00:16 > 34 active channels Well, these guys (GenChannel) are only supposed to be created in the autopatch code: Wonder how we are triggering that... ---
**Author:** ![N8RAW](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8raw/32/2906_2.png) [@N8RAW](https://community.allstarlink.org/u/N8RAW)\ **Post date:** [August 26, 2026, 3:13pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/12 "2026-08-26T15:13:55Z")
I'm thinking our problem is here: > If we are in "simple" autopatch mode, the local\_dtmp\_helper is launching the autopatch function... This is set to "simple" if there is no functions configured. > Something to check/try? ---
**Author:** ![K6MBY](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/32/5022_2.png) [@K6MBY](https://community.allstarlink.org/u/K6MBY)\ **Post date:** [August 26, 2026, 3:23pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/13 "2026-08-26T15:23:34Z")
Ran the test with both RTCMs completely disconnected — zero possible DTMF source anywhere in the system, voter node confirmed showing no connected clients. `Local/Autopatch@default` (Ring/Down) and `Local/GenChannel@default` still appear identically, ~13 seconds after establishing the link — same as before. This rules out DTMF entirely. Whatever's opening that autopatch channel happens purely from establishing the link between the Voter node (1998) and the SimpleUSB node (1996) in `duplex=0`/`linktolink=yes` mode — no DTMF, no RTCM, no real signal of any kind required. ---
**Author:** ![N8RAW](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8raw/32/2906_2.png) [@N8RAW](https://community.allstarlink.org/u/N8RAW)\ **Post date:** [August 26, 2026, 4:25pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/14 "2026-08-26T16:25:46Z")
Can you share your config files with us? Make sure to hide any secrets in there. FWIW, the DTMF code path is followed with startup scripts. There are only 2 paths to run the code which creates the GenChannel (that I see). Option 1 is simple patch mode (shown above)l Option 2 is using a macro that call `autopatchup` function under `[functions]` Option 1 is "enabled" when there is no `[functions]` making "option 2" not possilble. It may help to have a `[functions]` context and maybe even leave 61 and 62 so that \*is not the "only" way to bring up the autopatch. Another way to "prove" it's in simple mode would be to send a `#`\* on the channel to hangup - that "should" clear the fast busy. ---
**Author:** ![K6MBY](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/32/5022_2.png) [@K6MBY](https://community.allstarlink.org/u/K6MBY)\ **Post date:** [August 26, 2026, 5:12pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/15 "2026-08-26T17:12:29Z")
[rpt.conf.txt](https://community.allstarlink.org/uploads/short-url/hteqjtmz0cXvhloygtecNANPJBG.txt) (35.0 KB) [voter.conf.txt](https://community.allstarlink.org/uploads/short-url/tA0PkfxRxYSJ7yWHZdJBK6SiIRC.txt) (5.6 KB) [simpleusb.conf.txt](https://community.allstarlink.org/uploads/short-url/9Mm6FDNZC5WkLYAjzmckZ7mWwOS.txt) (8.6 KB) Sending # does stop the reorder tone. I un-commented 61 and 62 in functions with no change. ---
**Author:** ![K6MBY](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/32/5022_2.png) [@K6MBY](https://community.allstarlink.org/u/K6MBY)\ **Post date:** [August 26, 2026, 5:30pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/16 "2026-08-26T17:30:05Z")
Leaving. Back after 3:30 pm today ---
**Author:** ![N8RAW](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8raw/32/2906_2.png) [@N8RAW](https://community.allstarlink.org/u/N8RAW)\ **Post date:** [August 26, 2026, 6:22pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/17 "2026-08-26T18:22:42Z")
OK, I think the rpt.conf is "malformed". I believe the config for [1996] is not seeing the `functions=functions` config. Move [1996] and [1998] to the end of the original `[node-main](!)` template. Keeping your specific config for each node. Then add (node-main) -\> 1996 and ... 1998 ... > **···** > > On Wed, Aug 26, 2026 at 2:12 PM Bob \<[noreply@community.allstarlink.org](mailto:noreply@community.allstarlink.org)\> wrote: > > > Someone replied to your post. > > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/45/5022_2.png "K6MBY") | [K6MBY](https://community.allstarlink.org/u/k6mby) > > > August 26 | > > > > > > - | - | > > > > [rpt.conf.txt](https://community.allstarlink.org/uploads/short-url/hteqjtmz0cXvhloygtecNANPJBG.txt) (35.0 KB) > > > > [voter.conf.txt](https://community.allstarlink.org/uploads/short-url/tA0PkfxRxYSJ7yWHZdJBK6SiIRC.txt) (5.6 KB) > > > > [simpleusb.conf.txt](https://community.allstarlink.org/uploads/short-url/9Mm6FDNZC5WkLYAjzmckZ7mWwOS.txt) (8.6 KB) > > > > Sending # does stop the reorder tone. > > > > I un-commented 61 and 62 in functions with no change. > > > > * * * > > > > [Visit Topic](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/15) or reply to this email to respond. > > > > To unsubscribe from these emails, click here. Bad format - add `[1996](node-main)` ... `[1998](node-main)` ... ---
**Author:** ![WA3WCO](https://community.allstarlink.org/user_avatar/community.allstarlink.org/wa3wco/32/3123_2.png) [@WA3WCO](https://community.allstarlink.org/u/WA3WCO)\ **Post date:** [August 26, 2026, 6:38pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/18 "2026-08-26T18:38:33Z")
I would also suggest that you carefully read the [ASL Manual : Asterisk Templates](https://allstarlink.github.io/adv-topics/conftmpl/) page. Then, take a look at the template configuration files that were packaged with ASL3 and compare those with your modified .conf files : - `/usr/share/doc/asl3-asterisk-config/examples/configs/asl3/rpt.conf` - `/usr/share/doc/asl3-asterisk-config/examples/configs/asl3/simpleusb.conf` If you look at (and understand) your `rpt.conf` file, your `[1998]` node is only setting "6" variables. In your `simpleusb.conf` file, you set a few variables for `[usb_1996]` but inherits none of the template settings. I'm also curious about your `hiddev = /dev/hidraw0` setting, one that does not exist in ASL3. ... and those are just a few examples of where your configuration files have strayed. ---
**Author:** ![K6MBY](https://community.allstarlink.org/user_avatar/community.allstarlink.org/k6mby/32/5022_2.png) [@K6MBY](https://community.allstarlink.org/u/K6MBY)\ **Post date:** [August 27, 2026, 4:43am UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/19 "2026-08-27T04:43:36Z")
Moving the 1996 and 1998 to the end into the template area and adding the [node-main] appears to have fixed the issue. I now get a voice indicating the two nodes are linked. [1996](node-main) rxchannel = SimpleUSB/usb\_1996 duplex = 0 startup\_macro = \*31996 startup\_macro\_delay = 20 linktolink = yes archivedir = /var/spool/asterisk/monitor archiveformat = wav [1998](node-main) rxchannel = Voter/1998 duplex = 2 archivedir = /var/spool/asterisk/monitor archiveformat = wav And Alan, yes, had I read and understood how Asterisk uses templates it would have likely saved the time and frustration Thank you all for hanging in with me to solve this mistake. Bob k6mby ---
**Author:** ![WA3WCO](https://community.allstarlink.org/user_avatar/community.allstarlink.org/wa3wco/32/3123_2.png) [@WA3WCO](https://community.allstarlink.org/u/WA3WCO)\ **Post date:** [August 27, 2026, 12:02pm UTC](https://community.allstarlink.org/t/unwanted-reorder-or-fast-busy-tone/24944/20 "2026-08-27T12:02:32Z")
> [@K6MBY](#): > > Moving the 1996 and 1998 to the end into the template area and adding the [node-main] appears to have fixed the issue. Excellent. The templated configurations are "different" from other/older AllStarLink software packages but they do add / offer a lot of flexibility, especially for those with multiple nodes on the same server.