JNOS 2.0 is one of several many-featured IP-capable packet communications packages sharing a lineage which can be traced back to Phil Karn (KA9Q)'s KA9Q NOS. It provides IP connectivity, a BBS interface familiar to anyone who has used a TNC with a ROM mailbox or many other packet BBS systems, NET/ROM and ROSE routing and AX.25 digipeating, and any number of other services.
This page contains a collection of loosely organized notes on setting up a JNOS system to provide bulletin board services. I assume that you already know how to configure a Linux system, and that you have gotten JNOS at least as far as the jnos> prompt.
Soundmodem integration
KISS devices
NOTE: The following subsection on using net2kiss may not be necessary! I will leave it here for posterity's sake, and in case it is interesting for some other reason. However, Maiko Langelaar has pointed out to me that the baycom driver is capable of connecting directly to kernel AX.25 devices, and this indirection is no longer necessary. See the next subsection for details. (Note that I am not presently using soundmodem, but at some point I had various crashes using the baycom driver with soundmodem; your mileage may vary.)
As of 2.0g, JNOS does not seem to understand Linux AX.25 devices, but requires a KISS TNC interface. Soundmodem has provided as its primary interface a Linux AX.25 device for some time. In order to plumb these two together, one uses the net2kiss program from ax25-tools. See my AX.25 stuff page for more details.
Once the AX.25 interface is exposed as a KISS tty, simply set it up as you would any other TNC, using the KISS tty as the TNC device:
attach asy ptysm0 - ax25 vhf 4096 256 9600
Kernel AX.25 devices
As of JNOS version 2.0g, JNOS supports Linux AX.25 network devices directly, by way of the baycom hardware type. In order to use it, change the #undef BAYCOM_SER_FDX line in config.h to read:
#define BAYCOM_SER_FDX
Then recompile JNOS, and attach the soundmodem device in your autoexec.nos with:
attach baycom vhf 256 sm0
If your soundmodem network device is named something other than sm0, change the last parameter accordingly.
The JNOS documentation on this can be found on langelaar.net.
Many thanks to Maiko Langelaar himself for pointing this out.
TCP/IP
ifconfig <interface> netmask
The JNOS2 documentation gives examples using dotted-quad netmasks with ifconfig, but as of 2.0g it seems to require hex netmasks. (Verified in the source; netmasks use htol() for parsing.)
tun device configuration without root privileges
If you're like me, running JNOS as root makes you nervous. However, the default tun device configuration used to connect JNOS to the Linux host via IP requires superuser privileges, or at least CAP_NET_ADMIN, which can wreak havoc in and of itself.
Allowing JNOS to connect to the host Linux system via a tun device as a non-root user is simply a matter of preconfiguring the tun device as root, then attaching JNOS to the configured device. If the device is configured as persistent, then JNOS instances can attach and reattach over and over without further superuser intervention.
JNOS 2.0i requires a patch to allow for attaching an existing tun device. I have submitted the patch to Maiko Langelaar, and I hope that it (or some equivalent change) will be applied to a future JNOS release. In the meantime, apply the patch to your sources from the JNOS 2.0i source directory with:
patch -p0 < tun_existing.diff
After applying the patch, rebuild JNOS and copy the resultant jnos binary into the appropriate place on your system.
I wrote the simple program tuncreate to ease the task of configuring the tun device. It is available here in source form, and can be compiled with gcc -o tuncreate tuncreate.c. tuncreate creates a persistent tun device and sets its ownership to a non-root user of your choice. To create the device tun0 owned by the user elb, you would execute (as root):
tuncreate tun0 elb
Follow this up with whatever interface configuration your circumstances require, for example:
ifconfig tun0 192.168.2.1 pointopoint 192.168.2.2 mtu 1500 up
Once this is done, JNOS can use this tun device for IP communication with the host Linux machine. When attaching the tun device, add a fourth argument to the attach tun command, naming the device you created with tuncreate. For example, you might put the following commands in your autoexec.nos:
attach tun linux 1500 0 tun0 ifconfig linux ipaddress 192.168.2.2 ifconfig linux netmask 0xfffffffc ifconfig linux mtu 1500
You should now be able to ping back and forth across the tun device, as well as connect to any JNOS IP services from the Linux side of the divide and vice-versa.
Permissions
Preventing crashes
Buried in the JNOS manual is the sentence, "The <name> "univperm" should be included in the ftpusers file." This sentence is somewhat misleading — what it means is, if you fail to provide a univperm entry in ftpusers and a user without an explicit ftpusers account on your bbs runs one of a number of commands (such as w), your JNOS will crash. Make sure you have an entry like this in your ftpusers file:
univperm * /path/to/your/jnos/install/public 0x8
The 0x8 at the end indicates that unknown users coming in on AX.25 interfaces should be allowed to connect out on other AX.25 interfaces using the c command. See the JNOS documentation for other permission flags.
Remote BBS Identification
Remote BBSes are identified as such in the ftpusers permissions file by the permission value 0x2000. If this permission bit is set, the interface provided to the remote user is one which is useful for a remote BBS, rather than a human user.
BBS File listings
The FTP permission flags seem to be used for the w/u/d BBS commands. If you want anonymous users to be able to list and download files in the public directory, be sure to give them the FTP_READ permission (0x1) in ftpusers. A configuration which gives anonymous users permission to connect out on AX.25 and list readable files looks like:
univperm * /path/to/your/jnos/install/public 0x9
The value 0x9 is simply 0x1 (FTP_READ) + 0x8 (AX25_CMD).
Mail and bulletins
AX.25 BBS-style private mail forwarding
All of the information required to configure AX.25 BBS mail forwarding is present in the JNOS documentation, but it lacks a HOWTO on this process. This describes the configuration I struck upon for BBS forwarding.
There are two key concepts to understand for JNOS BBS mail forwarding. The first is that the rewrite file (see the JNOS documentation) rewrites destination addresses only as used for local delivery, and not in the message itself. The second is that arbitary private areas may be created and forwarded. Using these two facts, we can forward any private mail we wish to any given BBS. To do this, we send any mail we wish to forward to a given BBS to a private area reserved for the purpose, and then associate that area with the remote BBS in forward.bbs. For example, if we want to forward all mail for users @ kb8ojh to kb8ojh-5, we would put the following in spool/rewrite:
*@kb8ojh ojhbbs
The ojhbbs area is a special-purpose area used only for message forwarding; it need not contain only private mail, but it should contain only messages which we wish to forward to kb8ojh-5. You can use any area name you like, but it should be no more than six characters long. The JNOS documentation does not make this explicit, but a number of commands do not seem to work properly if it is longer than this.
In order to cause this area to forward to kb8ojh-5, we must create an entry in spool/forward.bbs. The full documentation for forward.bbs is in the JNOS documentation, but a sample record for our example is:
kb8ojh ax25 vhf kb8ojh-5 ojhbbs
The second and third lines here are where the magic happens. The second line states that connections to the kb8ojh system should happen via an ax25 connection to the station ID kb8ojh-5 via the interface 'vhf'. The third line says that, when we forward to this system, we should forward everything in the ojhbbs area. Provided that the BBS at kb8ojh-5 is configured to deliver mail to <user>@kbojh to local users, our rewrite rule plus this entry will ultimately result in private mails arriving at the appropriate destination.
The only remaining consideration is kicking off the mail forwards. Without some additional configuration, our mail for users of kb8ojh-5 will be spooled in the ojhbbs area without ever being sent. In order to cause forwards to be processed periodically, either the mbox forwarding timer must be configured, or the at command may be used to trigger mbox kick at desirable times. In the former case, mailbox forwarding must be turned on. To turn on forwarding and start the forwarding timer for 1 hour intervals, put these commands in your autoexec.nos:
start forwarding mbox timer 3600
Note that JNOS has very flexible forwarding configuration, and you can provide hourly restrictions, schedule specific contact times, etc. Consult the JNOS docs for more information.
