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.
You must be logged in to post a comment.