BPQ Packet Radio Node conversd Interlink

Usually, use of a plain telnet session is sufficient to connect to remote services in BPQ however when the remote service requires a login to occur, sending a prompt to the user and trusting them to input the correct information is unsatisfactory as in some circumstances this can lead to spoofing.

Automating with Expect

The expect tool is used in here to replace the interactive process of logging in with a preset behaviour.

The wrapper script connects to the remote service, in this case- conversd, and sends the command sequence including the callsign of the user to initialize the connection and log the person in with their current callsign connected through the BPQ node.

The callsign itself is provided to the wrapper script by BPQ32 automatically upon connect. The problem with conversd is that it requires a command prefix before the callsign to actually log in.

Install expect

You will need to ensure that the expect tool is installed on your system, and that the path to ‘expect’ matches in the script provided down below, by default this is /usr/bin/expect.

sudo apt install expect

The wrapper script

#!/usr/bin/expect 
gets stdin callsign
spawn -noecho nc IPADDRESS 3600
send "/n $callsign\n"
interact
exit

In the above example, substitute the IPADDRESS with the DNS host name or static IP address of the conversd server you wish to connect to.

You may need to substitute the port number for the one provided to you by the conversd owner. The default is usually port 3600, but it can sometimes differ system to system.

Place this script in a familiar directory, for the sake of example this document will use a sub directory “scripts” within the linbpq home directory.

/home/bpq/scripts/convwrap

Set the correct permissions:

chmod 755 /home/bpq/scripts/convwrap

Calling the wrapper script

The wrapper script by itself doesn’t do all of the work. Incoming connections from BPQ have to pass through to a TCP port that is connected to the wrapper script, this is easily achieved with the openbsd-inetd package.

Install ‘openbsd-inetd’ on your system, if using a Raspbian or Debian based install this is accomplished with:

sudo apt install openbsd-inetd

The openbsd-inetd utilizes two configuration files, these are:

/etc/inetd.conf
/etc/services

Edit the /etc/inetd.conf, insert the following tab-delimited configuration line.

convwrap    stream    tcp    nowait    bpq    /home/bpq/scripts/convwrap

Note that the references to ‘bpq’ here refer to the user ID that the service will run under. In the example, user ‘bpq’ runs the convwrap script from its own home directory. See Appendix 1 for more information on the inetd.conf syntax.

Edit the /etc/services file and insert a fresh port number for this service, e.g port 63000:

convwrap  63000/tcp

Restart inetd so that it loads the above configuration.

sudo service inetd restart

Configuring BPQ32

Insert an APPLICATION line below your existing application definitions, ensure that you select an unused unique application number (the digit after APPLICATION). BPQ has a maximum of 32 application definitions.

APPLICATION 9,WWC,ATTACH 10 127.0.0.1 63000 S,NOCALL-2,ALIAS,255

In the above example:

  • 9’ refers to application number 9, it is important that you choose an application number between 1-32 that is not already in use.
  • WWC is the command alias, a user connected to the BPQ node issues this command to initiate the connection to the wrapper.
  • ATTACH is the internal node command that requires a telnet PORTNUM.
  • 10’ is the telnet PORTNUM associated in bpq32.cfg, it will differ system to system, if your system does not have a telnet port defined, now is the time to do that
  • 127.0.0.1 63000 is the host and TCP port number where the wrapper script is provided (see /etc/services from earlier). 127.0.0.1 always refers to ‘localhost’ or ‘self’ in human terms
  • S’ is the internal node flag that instructs the node to keep the user connected to the node after disconnecting from the wrapper. This is known as ‘Stay’.
  • NOCALL-2 is the optional callsign and SSID you want the wrapper to be reachable via ax25 and NETROM.
  • ALIAS is the optional 1-6 character maximum unique ax25 and NETROM alias of the wrapper. Do NOT use the default- make sure you pick one that does not collide with anyone else on the NETROM network.
  • ‘255’ is the optional NETROM quality to add the prior optional call sign/alias to the NETROM broadcast, as it is a local and hard-wired service, this can be maximum, 255.

Testing

Test the wrapper using the simple telnet program. Connect to the wrapper port, it should show the following:

bpq@pe1rrr:~/scripts $ telnet localhost 63000
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

In order to emulate what BPQ will do, type in your callsign and hit enter.

pe1rrr
/n pe1rrr
*
* Access to channel 0 has been removed from this server.
*

FYI: No password found.
Try /help mkpass.

conversd @ Rijen_NL Ping-Pong conversd saupp-1.62a
* Type /HELP for help.
* Welcome to RRRWWC Worldwide Converse Server
* Use /help for commands.
* ========================================================
*
*** There are 18 users on 9 channels online.
*** Will try local default channel 3333.
*** You created a new channel 3333.
*** Personal data set from file: Red, Rijen, JO21LO
*** Nickname set from file: Red

🙂


Appendix 1

From the inetd.conf documentation:

service type protocol wait user server cmdline
service

The service name. Service names are translated to port numbers by looking them up in the services file (often /etc/services) for TCP and UDP services, or the portmap daemon for RPC services.

type

The type of socket the service will use. This will be either stream, for connection-oriented protocols, or dgram, for datagram protocols. TCP-based services should always use stream, while UDP-based services should use dgram.

protocol

The communication protocol used by the service. This must be a protocol listed in the protocols file (usually found in the same directory as the inetd configuration file). This is usually tcp or udp. RPC services prepend rpc/ to the type.

wait

Whether the service can process multiple requests at one time. This option applies only to dgram sockets. If the service in question can process multiple requests, this should be wait. Otherwise, and for stream sockets, this should be nowait.

user

The user under which the process should run. Oftentimes this will be root, but if the daemon does not require root privileges, you should consider running it under a less privileged user. Programs which you do not particularly trust, or that you know have security problems are prime candidates to be run under a less privileged user.

server

The absolute pathname of the daemon to be executed. Internal services are marked by the keyword internal.

cmdline

The command-line arguments to the daemon. The first argument should be the short name of the program. This is a traditional Unix convention which is normally hidden by the shell.

JNOS<>BPQ – Forwarding Mail over Telnet

UPDATE – Foreword: The easiest way to exchange mail between BPQ and JNOS would be to simply create a AXUDP link between BPQ and JNOS and then use NETROM connectivity to do regular AX25 connections over the link. The document below was composed before this realisation.

This foreword is here as a heads up that using Telnet method is really the longest route around the problem, and is really not recommended.

Internally Forwarding Mail to BPQ

Create a new user with BBS flags for your JNOS instance within the BPQ User Management Area.

For this account, do not use the callsign of the JNOS instance, instead use a descriptive alias. This avoids a problem with callsign collision which will usually cause JNOS to refuse to work. In my example, I will refer to this USER as RRRNOS on the BPQ side.

The HROUTE of RRRNOS is RRRNOS.PE1RRR.NLD.EURO, as configured in the mailbox settings for JNOS.

All mail for RRRNOS arrives first at PE1RRR.NLD.EURO and is queued for forwarding to RRRNOS.

In turn, we also will refer to the BPQMail instance in the JNOS configuration as MATRIX, rather than the callsign.

Configuring forward.bbs

IMPORTANT: The passwords for BPQ telnet sessions are NOT defined in the BPQMail User account, but instead in the bpq32.cfg node configuration file under the TELNET port declaration. See BPQ Telnet Server Documentation.

matrix 0023 P
telnet <bpq node address> <bpq fbbport> cronly
.<bpq port defined telnet userid>
.<password>
* 0
.BBS
* 0
<list of areas to forward>

IMPORTANT: The FBBPORT is often misunderstood as a direct connection to the BBS- when it is not. The port opens a connection to only the node which is why we must issue an extra command: .BBS

FBB sysops frequently get this wrong and wonder why their telnet forwarding to a BPQMail instance doesn't work.

JNOS ftpusers Configuration

It is necessary to provide BPQMail with an account on JNOS with which to log in and access BBS functions. This is possible by adding an account with the necessary privileges set.

JNOS won’t allow the use of an invalid callsign for a login user ID by default, to do so would require recompiling the JNOS source with one of the config.h “defines” changed (it is easy to do, but not recommended).

A workaround, if forwarding downstream to yourself– is to just use your own callsign for the login, as it would be coming from your own upstream BPQMail BBS anyway.

Permissions needed (if not using your own sysop login): Expert, BBS.

From the FTPUSERS PERMISSIONS reference sheet, sum up the permission level as such:

  • BBS: 8192
  • Expert: 16384
  • Summed together: 24576
FTPUSERS PERMISSIONS
The following is a list of the user permission values allowed in FTPUSERS file.
  Name          value    hex value    comments
FTP_READ         1        0x1       /* Read files */
FTP_CREATE       2        0x2       /* Create new files */
FTP_WRITE        4        0x4       /* Overwrite or delete existing files */
AX25_CMD         8        0x8       /* AX.25 gateway operation allowed */
TELNET_CMD       16       0x10      /* Telnet gateway operation allowed */
NETROM_CMD       32       0x20      /* NET/ROM gateway operation allowed */
SYSOP_CMD        64       0x40      /* Remote sysop access allowed */
EXCLUDED_CMD     128      0x80      /* This user is banned from the BBS */
PPP_ACCESS_PRIV  256      0x100     /* bit for PPP connection */
PPP_PWD_LOOKUP   512      0x200     /* Priv bit for peerID/pass lookup */
NO_SENDCMD       1024     0x400     /* Disallow send command */
NO_READCMD       2048     0x800     /* Disallow read command */
NO_3PARTY        4096     0x1000    /* Disallow third-party mail */
IS_BBS           8192     0x2000    /* This user is a bbs */
IS_EXPERT        16384    0x4000    /* This user is an expert */
NO_CONVERS       32768    0x8000    /* Disallow convers command */
NO_ESCAPE        65536    0x10000   /* Default is no escape char */
NO_LISTS         131072   0x20000   /* No lists displayed from mailbox */
NO_LINKEDTO      262144   0x40000   /* Disable '*** linked to'  */
NO_LASTREAD      524288   0X80000   /* Ignore lastread in <area>.usr
                                       (shared accts)*/
NO-FBBCMP        1048576  0x100000  /* Avoid FBB compression */
XG_ALLOWED       2097152  0X200000  /* Allow XG (dynip route) cmd */

Edit the ftpusers file and append:

<callsign> <password> /jnos/public 24576

Note: If this BBS is also a regular user, give them AX and netrom permissions too (add 8 + 32 to the final sum).

Configuring BPQ Forwarding

The BPQ User created with the BBS flag (RRRNOS in this example) should be visible in the Forwarding Management Area of BPQ as one of the callsigns in the list.

Click on RRRNOS user and then set the fields with the following information, if not explicitly mentioned, the fields are to be left empty.

Connect Script

ATTACH 10
C <jnos host/ip> <jnos port> TELNET <jnos userid> <jnos password>

BBS HA

RRRNOS.PE1RRR.NLD.EURO

Hierarchical Routes (Flood Bulls)

AF
AS
OC
EURO
NOAM
SOAM
CEAM
WW

HR (Personals and Directed Bulls)

WW

Enabled Checkbox/Flags (all not explicitly mentioned should be disabled)

  • Enable Forwarding [ON] Interval [600]
  • FBB Blocked [ON] Max Block [10000]
  • Send new messages without waiting for poll timer [ON]
  • Allow Binary [ON]
  • Use B2 Protocol [ON]

Click Update to finish.

Check and Test

Open a new terminal an go to your BPQ directory, open the log file using the tail command, this will open the log file and checks the file for new data is written to it every 0.1 seconds.

tail -f -s 0.1 logLatest_BBS.txt

From the BPQ Forwarding Area, select the BBS account and click Forward

Alternatively use: fwd <callsign> now from the BPQ mail prompt.

Watch the log file for errors.

If all goes well this is what you should see:

200213 16:31:41 |RRRNOS    Incoming Connect from RRRNOS
200213 16:31:41 >RRRNOS    [BPQ-6.0.19.30-B2FWIHJM$]
200213 16:31:41 >RRRNOS    0 messages to fwd to RRRNOS
200213 16:31:41 >RRRNOS    PE1RRR BBS>
200213 16:31:41 <RRRNOS    [JNOS-2.0m-B2FHIM$]
200213 16:31:42 <RRRNOS    FF
200213 16:31:42 >RRRNOS    FQ
200213 16:31:42 |RRRNOS    RRRNOS Disconnected

To test from the other direction, log into JNOS sysop console and issue:

Note: In the examples below. ‘MATRIX’ is the arbitrary name I have given to the BPQ mailbox in JNOS, it just so happens to also be the BPQ mailbox’s NETROM alias but that is not important at all as this is a telnet session, it is just for practicality.

mbox kick <bpq bbs name defined in forward.bbs>
e.g.
mbox kick MATRIX

Note: when calling mbox kick, use upper case for the callsign if there is no local mail to actually forward. This initiates a reverse forward. If you don’t use this method, and you have no mail to forward, it won’t try and connect, and as such you won’t see diddly squat happening in the log file.