Anatomy of a bpq32.cfg

📡 Why this page exists

BPQ32 has a reputation for being hard to configure. It isn't, really — it's just that a mature node's configuration is one flat text file holding eight different jobs at once, with no headings to tell you where one ends and the next begins. I have been running this node for over a decade, so this page takes its live bpq32.cfg and walks through it block by block: what each section does, why the values are what they are, and which mistakes cost me the most time. Everything shown here is taken from the running node, with all credentials removed.

Hours UTC — dial frequencies — bands overlap deliberately: one radio, several modes

Two rigs, three interlock groups, 24 ports. The amber and cyan rows are drawn straight from two RADIO blocks in the configuration — BPQ retunes those radios itself, on a clock. The dashed row is a third rig on a fixed frequency with no CAT control, so it has no RADIO block at all.

Section 1

Reading the file before editing it

Four syntax rules explain most of the confusion. Learn these and the file stops looking arbitrary.

The four structural devices

;

Line comment. This is how you park a setting instead of deleting it — my file has whole disabled ports sitting there commented out, which is documentation of what I tried.

/* … */

Comment block. Useful for long explanations, but easy to get wrong: forget the closing */ and BPQ silently swallows the rest of your configuration.

KEYWORD: … ***

A text block, used by IDMSG, BTEXT, INFOMSG, CTEXT and ROUTES. No line inside the block may start with *** — that terminates it early and the rest of your text becomes garbage configuration.

PORT … ENDPORT

One radio, modem or link per block. Indentation is cosmetic; BPQ does not care.

Section 2 — top of file

Who the node is, and what it says

The first thirty lines are pure identity. Nothing here affects routing; it is all about what humans and maps see.

Identity block, secrets redacted

There are four separate texts and new sysops mix them up constantly. They are not interchangeable:

The four texts and their byte limits

My INFOMSG is the station's real front page: the whole frequency and mode schedule lives there, band by band and hour by hour, because that is the one thing every visiting operator actually wants to know. It sits close to the 2047-byte ceiling — worth knowing, because BPQ truncates rather than complaining.

Section 3 — global parameters

Timers and table sizes

This block tunes NET/ROM routing and AX.25 link behaviour for the whole node. The defaults in the shipped example are sane; these are mine after years of watching a busy, HF-heavy node.

Global network and Level 2 parameters

PACLEN=236

The single most important number in the file. 236 bytes is the maximum a NET/ROM Layer 4 frame can carry. Set it higher anywhere NET/ROM is in the path and your traffic gets fragmented — you will see slow, retry-heavy sessions and blame the radio. The global value here is for sessions through other nodes; each port can override it for direct connects, which is why my HF ports use 100 and my internet ports use 253.

OBSINIT / OBSMIN

An ageing counter. A node heard once gets 5 and loses a point every NODESINTERVAL; at 3 we stop advertising it onward. This is what keeps a dead station from haunting the network for hours.

MINQUAL=50

Route quality is 0–255, higher is better. Anything below 50 never enters my table — cheap protection against a distant, marginal path being advertised as usable.

IDLETIME=720

Twelve minutes. Long enough that a Pactor session pausing to decode does not get torn down, short enough that a dead HF link frees its channel.

Section 4 — the part most people never use

RADIO blocks: BPQ tunes your rig for you

This is the feature that turns a node into an unattended HF station, and it is the feature I get asked about most. A RADIO block gives BPQ CAT control of a transceiver, plus a time-of-day schedule of frequencies to sit on. The chart at the top of this page is nothing more than a drawing of two such blocks.

RADIO 2 — the TS-570, four scheduled band changes a day

Reading one frequency line left to right:

30

Scan dwell / priority for this entry.

3.59112

The dial frequency in MHz — not the centre of the audio tone. Getting this distinction wrong is the classic reason two stations never hear each other on HF digital.

USB

Rig mode to select.

P123

Which Pactor levels to accept here. The TS-570 chain does Pactor 1–3; the TS-450 with its P4dragon does P1234.

VW

Also accept VARA and Winmor-class connections on this slot.

A500M / A2000M

ARDOP bandwidth cap — 500 Hz on the narrow rig, 2000 Hz on the wide one.

APPL=BBS

Where an incoming caller lands: BBS for the mailbox, RMSHF for the Winlink gateway. Same radio, same frequency, different service depending on the hour.

The times are UTC and, importantly, the list wraps at midnight — the entry written before the first timestamp is the 00:00 entry. Note also that the block terminator here is ****, four asterisks, not the three that end a text block. A small inconsistency, and a real source of head-scratching.

Choosing those hours by hand is guesswork, so I do not: a small propagation-driven generator picks the bands from live VOACAP predictions, and the schedule you see is regenerated rather than typed. Worth saying plainly, though — a RADIO block change needs the node restarted before it takes effect, so this is not something to automate blindly end to end.

Section 5 — the bulk of the file

Twenty-four ports, seven kinds of thing

A "port" in BPQ is any path packets can travel: a radio, a soundcard modem, a hardware TNC, a UDP tunnel over the internet, or the telnet server. They all use the same PORT … ENDPORT syntax, which is what makes the port list look intimidating and is also what makes it learnable — once you can read one port, you can read all of them. The table below is grouped the way the station is actually built: by which physical radio each port shares. That grouping is the INTERLOCK value, and it is the subject of the next section.

All 24 active ports, grouped by the radio they share

Port 7 is the simplest useful port in the file — a hardware TNC in KISS mode on a serial cable. Every radio port is a variation on this.

Port 7 — 70 cm, 9600 baud, hardware TNC

Notice how the timers scale with the medium. On this fast, local UHF port FRACK is 2 seconds. On my HF Robust Packet ports it is 8 seconds with PACLEN=100, because a 300-baud HF frame legitimately takes that long and an impatient retry only makes the congestion worse. Tuning BPQ for HF is mostly the discipline of slowing everything down.

QUALITY=0 means "do not run NET/ROM routing over this port". That is exactly right for ports 5, 6, 11 and the IL2P pair — an APRS or experimental channel has no business carrying the network's routing table. But set it accidentally on a port that carries users, and you have quietly cut off a chunk of the network with no error anywhere. I keep the intent written in the file itself: QUALITY=0 ; Default to NETROM OFF.

Section 6 — the HF concept that matters most

INTERLOCK: sixteen ports, three radios

Look again at the port table. Ports 14, 20, 21, 22, 23, 24, 25 and 26 are eight separate ports — Pactor, VARA, ARDOP, three flavours of soundcard packet, two of IL2P — and they are all connected to one transceiver. Only one of them may transmit at a time. Nothing in the layout of the file tells BPQ that. One keyword does.

The whole mechanism

Ports sharing an INTERLOCK number are mutually exclusive: BPQ will not key one while another in the group is active. My three groups are 1 the 30 m rig, 2 the TS-450, and 3 the TS-570. Get this wrong and the symptom is not a configuration error — it is two modems transmitting into the same antenna relay.

Two related keywords tidy up the same problem from the driver side. BUSYHOLD 1 and BUSYWAIT 20 appear in all my Pactor and ARDOP blocks: wait one second after the channel reports clear before believing it, and give up on a connect attempt after 20 seconds of a busy channel. That is basic courtesy on a shared HF band, and it is off by default.

Section 7

Wormholes: AX.25 over the internet

Packet radio did not shrink to one town — it links continents, and it does so over UDP. The BPQAXIP driver wraps AX.25 frames in UDP datagrams so a node in Bollate and one in New Zealand are neighbours as far as the routing table is concerned.

Port 3 — the worldwide wormhole (peer list trimmed out of respect for the other stations)

MAP call host UDP port B

One line per partner: their callsign, their hostname or IP, their UDP port, and B for "this peer speaks the BPQ AXUDP format". Dynamic-DNS names are normal here — most home stations do not have a fixed address.

QUALITY=161

Deliberately just above my best radio port. When both a radio path and an internet path to the same destination exist, I want the internet one preferred — it is faster and does not consume airtime.

Separate ports per purpose

I run three AXUDP ports rather than one big list: port 3 for worldwide partners, port 4 for my own (X)NET node over HAMNET, port 19 for the Linux subsystem on the same PC. Different UDP ports, different quality, and a fault in one does not take the others down.

Worth being precise about one thing that confuses newcomers: HAMNET and AMPRNet both use 44.x addresses but they are different networks. HAMNET is a BGP-routed European fabric; AMPRNet is the global IPIP mesh. A node can sit on both, as mine does, but the routing is independent.

Section 8

The telnet port is really the application port

Port 2 looks like "the telnet server" and is much more than that. It is the single place where BPQ meets the IP world: the login prompt, the web interface, the Winlink CMS connection, and the hooks that let your own programs become node commands.

Port 2, credentials redacted

FALLBACKTORELAY deserves a mention: it is the difference between a Winlink user on HF getting "no CMS available" and getting quietly handed to my local mailbox when my internet connection is down. Two lines, and the station keeps working during an outage — which is rather the point of amateur radio.

CMDPORT is the extension point, and it is underused because the indexing catches everyone out. The numbers are TCP ports your programs listen on; BPQ refers to them by position in the list, not by port number — and that position is counted from zero. With a single entry, as I have now, the only index is HOST 0. With three it would be:

CMDPORT positions are zero-based — an illustration

That example is not academic: it is what my own file held until recently. Nothing was ever listening on 4719 or 7373 — they were leftovers from an earlier application — so I removed them, which shifted 63000 from index 2 to index 0 and meant the APPLICATION line had to be renumbered from HOST 2 to HOST 0 in the same edit. Change one without the other and BPQ cheerfully connects to a socket with no listener: no error, no log entry, the user's session simply dies. So — append new ports to the end rather than inserting them, because inserting one renumbers every HOST reference after it; and if an application breaks right after you touched CMDPORT, count the positions again from zero before looking anywhere else.

What users can type at the node prompt

The fields are: number, the command the user types, the node command it expands to, an optional callsign that reaches it directly, then an optional alias and quality to advertise it in the network's node list. So APPLICATION 2 means someone can type BBS at my prompt or connect straight to IW2OHX-8 from anywhere on the network and land in the same mailbox.

APPLICATION 11 is the one visitors comment on: type AI at the node prompt and you are talking to a language model restricted to amateur-radio questions, running on the Linux subsystem of the same PC and reached through HOST 0 — TCP 63000, the only entry in the CMDPORT list. It is about fifteen lines of configuration and a small listener program. The lesson is that the extension mechanism is genuinely easy — the only hard requirement is that your program must flush its output after every write, or the session hangs with no diagnostic. Test the listener with nc localhost 63000 before you ever wire it into BPQ.

Section 9

WL2KREPORT: telling the world you exist

A Winlink gateway is useless if nobody knows its frequency and schedule. Each WL2KREPORT line publishes one frequency-and-mode slot to the Winlink channel list, which is what users' clients consult when choosing whom to call.

One advertised slot

Three details that cost me real debugging time:

• The frequency is in hertz and it is the centre frequency — dial plus the audio offset, typically +1500 Hz. My ports advertise 14110400 where the rig sits on a 14.1089 MHz dial. Publish the dial frequency by mistake and every caller is 1.5 kHz off.
• Hours use UTC and can wrap: 20-23:00-04 is the 80 m night slot crossing midnight.
• Only the Winlink-facing ports carry these lines. My BBS-only frequencies are deliberately absent — they are published in INFOMSG for humans, not to Winlink's channel list. Which means a BBS-schedule change needs no WL2KREPORT edit at all, and a habit of "update everything" wastes time here.

The same keyword appears on a VHF port too, advertising 1200 and 9600 baud packet access — the mode string is PKT1200 or PKT9600 rather than VARA, but the shape of the line is identical.

Section 10

APRSDIGI: a second, separate network

BPQ contains a full APRS digipeater and internet gateway. It lives in its own block with its own callsign and its own rules, and it can use any subset of your ports.

The APRS digipeater block, passcode redacted

Digimap is the interesting one, because it is a routing matrix and its defaults are generous. Digimap 6=IS says: take everything heard on port 6, send it to the internet, and do not retransmit it on RF. That is the responsible setting for a gateway in a dense area — the alternative is contributing to the congestion. MaxTraceHops=2 is the same instinct: two hops is plenty in the Po valley, and honouring a WIDE7-7 request would just be rude.

Note the coordinate format. LAT=4532.77N is degrees-and-decimal-minutes, the APRS convention — while LOCATOR at the top of the file wants decimal degrees. Same station, same file, two formats, and a silently wrong position on the map if you mix them up.

Section 11

Ten years, ten things I would tell my earlier self

None of these are exotic. All of them cost me an evening at least once.

Section 12

Where to start, if this is your first node

Do not start from a file like mine. Twenty-four ports is more than a decade of accretion, and every one of them was added to solve a problem I actually had. Start from the minimal example that ships with BPQ32 — the loopback-only configuration whose comment header is, entertainingly, still sitting at the top of my own file — and add one port at a time.

A sequence that works:

• Identity only. NODECALL, NODEALIAS, CTEXT, and the loopback port. Connect to yourself.
• Add the telnet port. Now you can log in and use the node commands — PORTS, NODES, ROUTES, USERS, MHEARD. Learn to read those before adding anything else, because they are how you will diagnose everything later.
• Add one radio port with a TNC you know works. Get a direct AX.25 connection with a friend.
• Add one AXUDP wormhole to a nearby node. You now have a network, and NODES starts filling up on its own.
• Only then think about HF, Pactor, VARA and INTERLOCK.

The authoritative reference is G8BPQ's own documentation, and the BPQ32 group on groups.io is where John himself answers questions — patiently, and usually within a day. This page is a companion to those, not a replacement: it is the annotated example I wish had existed when I started.