BPQ The Switch
- 1 The Switch
- 1.1 Introduction
- 1.2 The switch command set
- 1.3 Sysop access
- 1.4 Application basics
- 1.5 Port basics
- 1.6 The switch in action
- 1.7 Callsigns
- 1.8 Gathering switch data
- 1.9 Initiating a connection
- 2 Related Links
In BPQ speech applications are the components which offer functionality to users. On the HF bands applications are invoked by directly connecting to a dedicated station using one of the digital modes with the most popular applications being BBS and the WL2K internet email gateways. On VHF and above networks of interlinked nodes are needed to connect to an application because of the short range of links on these frequency bands.
The BPQ switch supports both scenarios. It can be used as a (packet radio) node where users initiate outbound connections to the next node in the network and it can as well be used to invoke locally available applications.
The switch can be accessed via BPQ ports and via the local terminal.
The switch command set
The switch is used with a command line interface called the "node command interpreter" (NCI) which takes single-line commands and supports four types of commands:
- initiate outbound connetions
- invoke local applications
- gather system information
- perform administrative tasks
The commands are described in detail in the corresponding sections. All commands may be abbreviated as long as they are still unique and are case insensitive.
Important commands you will need include:
|?||lists all available NCI commands|
|STATS||general statistics of the system|
|BYE||closes the connection with the switch|
Those NCI commands which may have an impact on the operation of the system as a whole require extended privileges called SYSOP privileges. Examples for such commands are:
|RECONFIG||reread and apply the BPQ config|
reboot your computer (if the user running BPQ has the appropriate OS rights for this)
As the switch does for simplicity not have a user management of it's own SYSOP privileges are acquired by knowing a certain secret (password).
The switch SYSOP secret is configured with the PASSWORD directive in bpq32.cfg. Choose a lengthy string that you can easily remember.
The password command entry is case insensitive.
On the local BPQ terminal and via network connections (telnet, remote terminal) the password is not required to acquire SYSOP privileges. Simply enter the command "password" at the prompt:
password DB0NTS-2} Ok
In all other cases (i.e. connecting from remote e.g. via packet radio) the password command responds with a series of 5 random numbers. Enter the string "password" followed by the corresponding 5 characters of the PASSWORD string:
password DB0NTS-2} 3 4 11 5 15 password etlwh DB0NTS-2} Ok
Please note that the rights system of applications are unrelated to the switch and that the sysop status is not propagated in any way to applications being invoked from the switch. Privileged accounts in BBS are usually also called sysop but please do not mix them up with the switch sysop status.
You can have at most eight applications in a BPQ installation. These are configured with the APPLICATION keyword:
numerical id of the application from 1 to 32; some ids are reserved (2 = chat, 32 = sysop chat)
the name of the application; this will be available as an NCI command e.g. "BBS"
used if the application is a single command at the switch typically a connect to another packet radio node
|call, alias, L2alias|| application callsign(s)
An incoming connection to one of these callsigns will automatically invoke the application. L2Alias is available from KISS ports only (???).
|quality||routing quality used for connections with this application|
If you need an application to play with best use the sysop chat although it cannot initiate outbound connections. This application has the built-in id 32:
When you issue the BELL command at the switch terminal a new window will pop up in the BPQ console to chat with yourself.
The communication mechanism between the switch and an application is called "streams". We mention the streams mechanism here because you can see all application streams in use in the Streams Status Window (see below).
Each connection with an application (both inbound and outbound) requires one stream. The endpoint of a stream at the switch is known as it's circuit.
The streams status window in the console shows all allocated streams together with the application ids, the callsigns of the connected users (if any), and the name of the application program.
You will notice that the local BPQ terminal (not the TCP version) is also implemented using the streams interface having application id 0.
Application names are available as additional NCI command names and are listed in the output of the "?" command. Application names starting with an asterisk (e.g. *RMSHF or *BBS) are not listed but they can also be invoked by name. As an alternative you can initiate a connect to the application callsign (if any) to invoke the application. See the section on callsigns below.
Before we discuss how users connect to applications we first need some basic knowledge on ports.
Ports abstract inbound and outbound connections on external interfaces into circuits on the switch. Depending on the type of port the streams mechanism may be used for the communication between the port and the switch. The Pactor and telnet ports use it whereas it is not used for KISS ports.
Inbound connections on ports (devices) are referred to as upstream and outbound connections on ports (devices) are referred to as downstream.
Ports are identified by number and have an additional descriptive name.
More details on ports can be found in the respective chapter.
A typical port configuration looks like this:
[bpq32.cfg] PORT ID=PTC PORTNUM=2 DRIVER=SCSPactor ... ... ... CONFIG ... ... ... ENDPORT
General parameters for the port are listed first and specific configuration for the particular port follow the CONFIG statement.
|ID||description of the port (30 chars max)|
|PORTNUM||number of the port; this is unique for every port|
|DRIVER||the driver to use for the device to control i.e. the type of device|
The switch in action
As we have seen above the switch has circuits from both ports and applications:
+--------+ +----------+ +--------+ | port 1 |---|-c c-|---| appli- | | |---|-c c-|---| cation | +--------+ | c-|---| A | +--------+ | c-|---| | | port 2 |---|-c switch | +--------+ | |---|-c | +--------+ +--------+ | c-|---| appli- | +--------+ | c-|---| cation | | port 3 |---|-c c-|---| B | | |---|-c c-|---| | +--------+ +----------+ +--------+ c = circuit
A connection through the switch links the circuit of an inbound (upstream) connection with a circuit of an outbound (downstream) connection. This is exactly how a classical telephone switchboard works. As both circuits may originate from either a port or an application we have a total of four different cases:
upstream port circuit linked to downstream port circuit
An upstream connection on a port is sent downstream to a(nother) port. This is how digipeaters work.
upstream port circuit linked to downstream application circuit
An inbound connection on a port is linked to an application.
upstream application circuit linked to downstream port circuit
An application makes an outbound connection on a port e.g. an outbound BBS call to forward messages.
upstream application circuit linked to downstream application circuit
This happens rarely as it means that one application talks to another one. The only real use case is that you connect from the BPQ terminal to an application.
The following diagram shows an example in which a BBS has both an inbound and an outbound connection at the same time and the sysop chat application is also in use. Both applications have unused streams.
+--------+ +--------------+ +--------+ ----->| port 1 |--|-c->------>-c-|--| appli- | inbound conn on port 1 | Pactor | | c-|--| cation | +--------+ | -<-c-|--| BBS | outbound conn on port 2 conn- | switch / | +--------+ ections | / | | / | +--------+ +--------+ | / c-|--| appl. | <-----| port 2 |--|-c-<- c-|--| sysop | ----->| Packet |--|-c->------>-c-|--| chat | inbound conn on port 2 +--------+ +--------------+ +--------+ c = circuit
A callsign is used at every circuit and a link through the switch thus involves a source callsign from the upstream connection and a destination callsign (downstream) the connect is made to.
The basic idea for inbound calls is that a user connects to a callsign which may either represent another station/ user (case 1. above) or an application (case 2. above).
This requires that port devices can accept inbound connections for multiple callsigns a concept which is suitable for packet radio. On HF things are a little different as ARQ modes are usually employed for reliable communications and the controllers used to this end typically support only a single callsign. Therefore on HF applications are usually invoked by calling on application specific frequencies.
In conclusion applications need either be alloted to callsigns/ SSIDs (packet radio) or to frequencies (ARQ modes) using a single callsign for all applications. However everything depends on the capabilities of the devices.
Callsigns have a maximum of six characters in BPQ and may optionally be followed by an SSID. This has been taken over from the packet radio world (MARS station with seven character callsigns have their own convention on how to deal with this).
The most important callsign in your configuration is the NODECALL, the callsign belonging to the switch.
Even if you decide not to make the node accessible to users by choosing NODE=0 in the main configuration it is recommended to set the NODECALL (which you do not need to in this particular case). This is because a connection from a terminal window of the console to an application will otherwise use an empty callsign. However, you do not need to set the NODEALIAS.
; node not accessible to users NODE=0 NODECALL=CALLSIGN NODEALIAS=;
In case you make the node accessible to users (which is the default) by choosing NODE=1 set at least the NODECALL to your callsign followed by an optional SSID. If you specify the NODEALIAS as well the CLI prompt will read
The NODECALL is used as a fallback in certain cases. See below for more.
Callsigns upstream and downstream
The callsign a connection initiates from (upstream) is preserved by BPQ. Thus the identity of users is preserved for inbound calls (cases 1. and 2. above). As simple this concept is it may even have legal implications. Think of a user connecting to a packet radio port upstream and initiating an outgoing call on a HF pactor port. His callsign will appear on HF as the sender's call from your station.
Applications identify themselves by using their application callsign. This is the callsign configured in the APPLICATION statement and the NODECALL is implied as a fallback if the former is not specified. Additionally you can have an alias as a second callsign. This takes effect only when the application callsign is specified, too.
Callsign usage may thus be unsymmetrically since the application callsign is not necessarily the one the user initially connected to. Think of invoking an application as connecting to it's application callsign.
In the following example the user DL4FN connects to the switch with the NODECALL DB0NTS-2 and invokes the sysop chat application BELL which has the application callsign DB0NTS-9.
user switch BELL appl. ---------------------------------------------------------------- DB0NTS-2 DE DL4FN ----> accept connect text <---- send CTEXT BELL command ----> invoke BELL --DE DL4FN--> accept set appl. call sysop chat <--------- DL4FN DE DB0NTS-9 -- sysop chat
For outbound connections (cases 3. and 4. above) an application uses it's application callsign or the NODECALL if there is no application callsign.
When an application is invoked (inbound call cases 2. and 4. above) it sets the application callsign on the stream and the alias in case the application has been invoked with this callsign.
Callsigns may be changed both upstream and downstream depending on the ENABLE_LINKED setting in the general BPQ config.
ENABLE_LINKED=N nobody is allowed to change their callsign ENABLE_LINKED=A applications may change their callsign ENABLE_LINKED=Y everybody is allowed to change their callsign
ENABLE_LINKED=Y eases callsign spoofing and is therefore not recommended. Setting ENABLE_LINKED=A allows applications (e.g. the BBS) to assume a given callsign for outbound calls. Additionally it also allows users with sysop privileges or those connected through a local network to change their callsign.
The switch command to change your callsign is "*** LINKED To [CALLSIGN]":
USER DB0NTS-2} G8BPQ Network System V184.108.40.206 for Win32 (720) TNC Uplink Port 1/1(DL4FN) � *** Linked To DF0NTS DB0NTS-2} Ok USER DB0NTS-2} G8BPQ Network System V220.127.116.11 for Win32 (720) TNC Uplink Port 1/1(DF0NTS)
The basic idea with callsign allotment is to expose all the callsigns of your applications on the port so that a user can directly connect to them.
The number of callsigns supported, the configuration statements to use, and other details are specific to the device in use.
The multiple callsign scenario can also be emulated on devices supporting only a single callsign. Think e.g. of a TNC supporting a single callsign only. Now switch the TNC to monitor mode and when a connect frame to one of the application callsigns is recognized then set this very callsign as the TNC callsign. The connect request will be accepted and the application corresponding to the callsign will be invoked.
Devices supporting a single callsign use the NODECALL by default unless the port specific PORTCALL is present in the port config. Connections to the latter invoke the switch or an application configured with the APPL keyword at the top of the CONFIG section.
Here is an example:
NODECALL=DB0NTS-2 ... ... ... PORT ID=PTC PORTNUM=2 DRIVER=SCSPactor ... ... ... PORTCALL=DB0NTS ; use this callsign for pactor MYCALL CONFIG APPL BBS ; invoke BBS for all inbound connections ... ... ... ENDPORT
Since the nodecall has an SSID which is not standard on HF a PORTCALL is configured and the APPL statement is used to route all connections coming in on this port to the BBS.
There may however be one caveat here depending on how the application for the BBS is configured. In case you set an application callsign e.g. "APPLICATION 1,BBS,,DB0NTS-8,,0" the application will set this on the stream and it will be visible to the caller.
APPL BBS DB0NTS DE DL4FN ---------> BBS | APPLICATION 1,BBS,,DB0NTS-8,,0 DL4FN DE DB0NTS-8 <-----------+
So it is best to set the application callsign to the PORTCALL and offer an alias for packet radio ("APPLICATION 1,BBS,,DB0NTS,DB0NTS-8 ,0").
When the application does not have an application callsign the PORTCALL is kept.
The rig control driver (aka scanner) supports the frequency allotment concept by extending the APPL keyword to be used on a per frequency base. Thus a connect to PORTCALL invokes frequency specific applications. Use the application name NODE to invoke the switch. Here is an example of a simple config:
NODECALL=DB0NTS-2 ... ... ... PORT ID=PTC PORTNUM=2 DRIVER=SCSPactor ... ... ... PORTCALL=DB0NTS CONFIG RIGCONTROL ; scanner config starts here COM2 9600 ICOM IC7410 0C 6,14.0979,USB,F2,P12,APPL=BBS ; appl. BBS on 14.0979 MHz 6,14.1124,USB,F1,P1234,APPL=RMSHF ; appl. RMSHF on 14.1124 MHz **** ; scanner config ends here ... ... ... ENDPORT APPLICATION 1,BBS,,DB0NTS APPLICATION 3,RMS,C 1 CMS,DB0NTS-10 APPLICATION 4,RMSHF,C 1 CMS
The columns in the scanner config lines are the scan time in seconds (6), the frequency to scan in MHz, mode and filter setting for the radio, pactor protocol levels, and the application to invoke. Details on the scanner can be found in one of the sections below.
The Pactor controller can be connected to on any scan frequency using the PORTCALL DB0NTS. Connecting on 14.0979 kHz (dial frequency) invokes the BBS which sets it's application callsign DB0NTS. From the perspective of the user the callsign does not change. However, the BBS can be connected to through other ports with it's application callsign.
Connecting on 14.1124 kHz (dial frequency) invokes the application RMSHF which does not have an application callsign. Therefore the PORTCALL DB0NTS is kept and the CWID sent by the Pactor controller is DB0NTS. This application is not accessible by a callsign but can be invoked by name at the switch only. This is why we have virtually the same application with a different name (RMS) and an application callsign (DB0NTS-10).
Emulating multiple callsigns
With the USEAPPLCALLSFORPACTOR keyword in the CONFIG section the scanner can also be employed to offer application callsigns to the user. Use the special application callsign NODE to access the BPQ node.
In the example
NODECALL=DB0NTS-2 ... ... ... PORT ID=PTC PORTNUM=2 DRIVER=SCSPactor ... ... ... PORTCALL=DB0NTS CONFIG RIGCONTROL ; scanner config starts here COM2 9600 ICOM IC7410 0C 6,14.0979,USB,F2,P12,APPL=BBS ; application BBS 6,14.0979,USB,F2,P12,APPL=RMS ; application RMS **** ; scanner config ends here USEAPPLCALLSFORPACTOR ; use application callsigns ... ... ... ENDPORT ... ... ... APPLICATION 1,BBS,,DB0NTS,,0 APPLICATION 3,RMS,C 1 CMS,DF0NTS,,0
the scanner changes the callsign on the pactor controller every 6 seconds from DB0NTS (BBS) to DF0NTS (RMS). Thus both applications are accessible on the same frequency depending on which callsign a user connects to.
Gathering switch data
The STATS command (abbreviated S) displays both port statistic and general statistical data for the node. Use the option S to show only the latter.
STATS S DB0NTS-2} Uptime (Days Hours Mins) 02:09:42 Semaphore Get-Rel/Clashes 1 325 Buffers:Max/Cur/Min/Out/Wait 730 729 706 0 0 Known Nodes/Max Nodes 0 512 L4 Connects Sent/Rxed 0 0 L4 Frames TX/RX/Resent/Reseq 0 0 0 0 L3 Frames Relayed 0
The USERS command (abbreivated U) lists all active sessions on the switch with the inbound (upstream) part shown on the left hand side and the outbound (downstream) part shown on the right hand side. The command output has three types of entries:
|TNC Uplink Port N/M(CALL)||
inbound connection from CALL on port N with M being the connection counter of the port
stream N using application callsign CALL (both upstream and downstream)
|Attached to Port N/M||
outbound connection on port N with M being the connection number of the port
Here is sample output for various cases:
upstream circuit to the switch (both port and application; inbound connection to the switch)
TNC Uplink Port 2/1(DL4FN) Host14(DB0NTS-2)
upstream port circuit linked to downstream port circuit (user initiated an outbound connection)
TNC Uplink Port 1/1(DF0NTS) <--> Attached to Port 2/5
upstream port circuit linked to downstream application circuit (user invoked an application)
TNC Uplink Port 1/1(DF0NTS) <--> Host11(DB0NTS-9)
upstream application circuit linked to downstream port circuit (outbound call of an application)
Host10(DB0NTS) <--> Attached to Port 2/5
upstream application circuit linked to downstream application circuit (application talking to application)
Host14(DB0NTS-2) <--> Host11(DB0NTS-2)
Note that neither application names nor ids are listed by the USERS command. You can obtain them from the stream numbers listed with the applications in the BPQ console stream status window.
Initiating a connection
The CONNECT command usually abbreviated with the single letter C is used to initiate outbound connections. Therefore the connect function of the port device will be internally used by the port driver. Device specific connect syntax (e.g. Pactor robust connect, packet radio routes) are supported.
After termination of your connection you will be disconnected from the switch as well.
At the NCI you can directly connect to an application by specifying it's callsign after the connect command e.g. "C DB0NTS-9".
Note however that this syntax is not supported with remote callsigns as BPQ needs to know which port to initiate the connect from.
Some devices only support a single connection. This is typical for controllers used with HF radios such as Pactor or Winmor. In order to initiate an outbound connection on a port with such a device you have to get a lock on the device first to gain exclusive access. This step is called "port attachment" and is performed with the ATTACH command at the switch.
To initiate an outbound connection on a single-connection port p you thus need two steps:
DB0NTS-2} ATTACH p DB0NTS-2} Ok C CALLSIGN
The string CALLSIGN is passed unmodified to the device interface which allows for the use of device specific connect syntax.
Parameters may as well be set on the port after attaching it e.g. for a Pactor port
DB0NTS-2} ATTACH p DB0NTS-2} Ok RADIO 7.050 USB 1 D DB0NTS-2} Ok MYLEVEL 3 DB0NTS-2} Ok C %DA5UDI
In this example the radio is first set to the given frequency in USB mode with filter 1 and data mode. Then the Pactor protocol level is set to 3. Since the string "%DA5UDI" is passed to the pactor controller without modification it initiates a robust connect to DA5UDI.
If you try to ATTACH a port which is already in use by someone else you will get an error message
ATTACH 2 DB0NTS-2} Error - Port in use
The attachment of a port ends after disconnecting. A connect failure will leave the port attached and you have to disconnect from the switch to release the port.
On devices supporting multiple concurrent connections e.g. packet radio controllers (TNCs) the port does not need to be attached and is specified within the connect command
C p CALLSIGN
In rare cases a port can both have a single-connection and a multi-connection part the most prominent example being SCS Pactor controllers with an additional socket for packet radio where the pactor part is single-connection and the packet radio part is multi-connection.
This connect syntax is mostly used for packet radio links. You can instruct the node to stay connected after the connection with the remote station is closed by adding an S (for "stay") at the end of the command. In the following example an outbound connection to DB0AAI via DB0BOS is established and when the connection is closed we are returned to the node instead of being disconnected:
C 2 DB0AAI DB0BOS S *** Connected to DB0AAI RMNC/FlexNet V3.3h =>quit 73! Returned to Node DB0NTS-2