CONFIGURING the JNOS NODE

To prepare jnos for use on the host, both JNOS and the host platform require configuration as discussed in this section of pages. The view from this section is services are defined by data in files, and jnos is started with references to files and parameters. JNOS communicates with the outside world thru I/O ports of various types, and services are provided by a collection of servers within jnos. Server conditions are totally supplied at start-up time from a combination of EnvironmentVars, CommandLineParms, and AutoexecNosFile.

As a starting point, consider the physical location of the host computer and radio controls. Because of licencing, consider the risks involved in open access to the sysop console, and access to jnos from Internet.

An important issue to consider in troubleshooting an installation is the effect of other services on jnos ability to communicate and access files. A firewall can stop internet communications cold. It typically works to disable the firewall while testing a configuration and re-enable the firewall after everything works, to retest with the firewall in effect. SELinux also manages security and can cause jnos to not work. Tripwire can be employed to safeguard the platform against intrusion via external links that jnos supports. If any of these type services are to coexist with the jnos application, then administration must apply to both jnos and the operating system.

TYING IT ALL TOGETHER

Later on this page we deal with the detail of the components. While no two configurations may be identical, it is reasonable to offer some examples that are up and running. What follows is description and attached configuration files used to impliment the goals of the owner. A convention followed here is that J0NOS is the owners call, J1NOS, J2NOS, are neighbor calls, 44.1.1.1 is the owner IP, 44.1.2.3 etc are remote IP addresses, and further substitutions are made for consistency between examples.

Here is a ExDrgHamgate part of MI-DRG. A gate always includes both RF and Internet ports, is registered with ampr.net, and supports selected services, all with routing data to tie the network together. To gain detail understanding of MI-DRG please refer to the DRG site, and feel free to download the example presented here.

Here is a ExDrgRemote example, again part of MI-DRG. This example is intended to be a model for a field station, or a flll-in when the Internet port is out of service. One of the attributes of this configuration is that two or more simultaneous paths are available for connection to MI-DRG network.

START-UP

The environment into which jnos will be installed is perhaps the first consideration. The means to start jnos are dictated by the site (open or secure), the platform (pick one), and staff (one or many).

Internet configuration considerations include selected interfaces with other jnos nodes, and local interfaces with an Internet Service Provider (ISP).

After the planning is turned into a fully configured site, jnos may be started by the method of choice. After jnos is started, the sysop relies on the SiteUser and SysopUser for operation of the site.

HARD DRIVE STRUCTURE

Like most applications, jnos requires space on the storage system, the hard drive. The default system is delivered with jnos directory tree defined in the root file system. In redefining the file system for jnos, consider overall use for the computer, and the approach to administration that will be employed. The space required for everything begins around a few megabytes (refer to the distribution for detail) and grows as mail and log data is accumulated. The computer backup strategy certainly needs to include the configuration files, but may not need to save log data.

Consider adjustments to the directory structure. The original design is set at compile time by FilesCFile. Some default configuration is delivered in every pre-compiled version, and the included NosCfgFile is delivered with hopefully the same layout. To redifine the directory structure for the site, the source may be recompiled, but an alternative may be applied at jnos load time by revising the NosCfgFile with your favorite editor. Detail discussion and samples are found in NosCfgFile page.

The default system is delivered with root permission as a requirement on Linux platforms. What this means for the platform is that the jnos process simply does not adhere to the system ownership rules. Any operation jnos performs is subject to security provided by jnos itself, but not from the platform. While the jnos community experience suggests this is safe, it violates standard security systems and may represent a risk. If tripwire and/or SElinux is enabled on the platform, the jnos area needs definition in the security rules before running the application.

On a multiuser platform, an alternative to be considered is to crete a user ID named "jnos" and use this account for maintenance purposes. Using this scenario administration may be performed with user rather than root priveledges. Further, a choice to copy or link the files from the user to the jnos area is available. In fact, the entire jnos directory structure might reside within the user file structure either by linking or redefinition.

Before starting jnos, at a minimum confirm the following files are configured:

COMMUNICATIONS

Communication is done via a combination of serial and network connections. JNOS2.0 supports many modes from a basic packet radio driver to full network connectivity including Internet.

The basic mode of communication is AX.25 spec for ascii data. The minimum required for this is a terminal (may be non-computer), modem, and radio. In this realm there are BBS facilities for users with mail, bulletin. and networked communications at the ascii level.

Network traffic between hosts is carried thru a variety of ports. Wired Ethernet and wireless Wi-Fi devices are supported, and on unix style platforms the ports are driven by the host stack. With Internet traffic between two network (jnos) nodes with 44... IP addresses, the packets are encapsulated into packets with IP addresses that are resolvable by DNS then de-encapsulated at the destination host. When carried over other paths such as radio using AX.25 prootoocol, the ports are driven by the jnos stack with encapsulating TCP/IP in AX.25 packets.

The examples here contain the portion of AutoexecNosFile to define network interfaces. The examples may be used for cut-and-paste into a file in ./etc directory for the site. Then source these commands into AutoexecNosFile to open the connection. This tactic facilitates variations of network connections for use - tun, ppp dialup, etc. The benefit of this approach is to develop several alternative configurations for the site, and to change the site wiring and a simple change to "source <file-name>" in AutoexecNosFile prior to returning to the air.

AX.25 (RF) RS-232 INTERFACE

JNOS2.0 allows local users to communicate with remote stations via Radio paths. A standard TAPR TNC2 with KISS protocol, and trancievers in HF, VHF, and UHF frequencies is the base configuration at speeds from 300 to 9600 bits per second. This wiki is developed against the base configuration, along with exceptions and extensions as they emerge. Consider that Clover and Pactor are not KISS compatable thus require custom HF server support for the protocols. JNOS2.0 also supports encapsulation of TCP/IP protocol over AX.25 interconnections so that network traffic may travel over the otherwise ascii AX.25 links. Did we mention PPP dial-up phone service for an option?

Computers with no (or too few) RS-232 interface but with USB interface may still run jnos. The good news about USB to RS-232 conversion devices is that many of them plug-and-play on unix platforms - the configuration references "/dev/ttyUSBn" (where n is found after it is plugged in) rather than "/dev/ttySn" (where n is one of the physical RS-232 interfaces). Some platforms vary...

Standard TNC with KISS is the subject for the TncTaprKiss tutorial pages. Jnos supports the KISS mode fully.

In addition, the exceptions and extensions may be found at:

TCP/IP NETWORK INTERFACE

One strength of a jnos site is the addition of TCP/IP network traffic. Jnos will accomodate both ports that are native to IP like ethernet, and ports native to AX.25 which carry IP as encapsulated packets. The site might be configured with private network IPs however for this discussion we consider Jnos is registered in the worldwide amprnet 44... network with one neighbor within reliable radio range.

As a matter of history, KA9Q's NET was developed with it's own TCP/IP stack (network traffic processing subroutine tree) on DOS platform and the concept has continued through to present day versions of Jnos on all platforms. The stack facilitates network communication for jnos using the TCP/IP protocols. When the underlying system platform establishes it's own stack, nos does not share use of the host stack but establishes a path (tunnel) between the two stacks within the one host.

Add other subjects here[tbd]: Static IP, VPN, ENCAP IP, DNS

Each page may have attached configuration files for both jnos and host platform. The example files contain both jnos and host script text. In the attached file examples named for "option.p?.txt". To create the actual file name substitute per:

Anal? Read on please for clarity...

Here we will consider AX.25 encap, TCP/IP LAN, the ampr.org IP 44... network, and Internet networks. The configuration discussion centers on the host and jnos ports, the optional LAN, and radio network neighbors. Let's begin with a jnos site with only ham radio links.

Tuning TCP/IP To begin the configuration process NetParmSet considers tuning communication for radio and wired networks.

Host & Ham Radio In NetNode the jnos host is a stand alone network node with only ham radio RF links to the IP network, and is potentially an unmanned, site.

AX node-to-node RF links may be configured in two manners, datagram and virtual channel. Implementation of AxDataVsVc option requires some cooperation with RF neighbors. The modes deserve consideration as a part of optimization and after review of channel performance.

Local Network Topology

There is a fair variety of ways to integrate IP over RF into the surrounding communication networks like LAN and public Internet. Some minimal routing information is presented only to the extent of making the configurtation work but not extending out beyond the local site.

Host + LAN subnet In NetLanSub the ampr.org network found on the air is extended beyond jnos to the LAN and place selected hosts on the ampr network.

Host + LAN + Internet Appliance In NetLanNode network the jnos host is a member of a LAN with Internet connectivity provided by a broadband (DNS, cable, wi-fi) appliance. Limitations imposed by choice of appliance is found here.

Host & Internet NIC In NetInternetNode network the jnos host has only Internet connectivity provided by a broadband (DNS, cable, wi-fi) appliance.

Host & Internet NIC + LAN In NetLanInternetNode network the jnos host is a member of a LAN with Internet connectivity provided by NIC directly. Other hosts on the LAN have access to servers on jnos.

Host & NAT + LAN In NetLanNat the LAN is a class C subnet with access to ampr.org network thru NAT to provide all LAN hosts full access to ampr network thru one IP address assigned to the jnos site. NOTE! this is preliminary idea and not implemented - a work-in-process.

Another View

This subject has had a fair amount of play in various places. To take another look from a seperate perspactive consider the tutorials in the following.

Configuring the "tun" bridge on a Linux platform to bridge the opeating system IP stack with the jnos IP stack. The tun device to bridge between the system stack and the jnos stack is the most recent and most efficient option available. Do check StackIpForward to validate ip_forward switch is "on". NetDevTun contains a tutorial on the steps to open the bridge to the host.

Replace SLATTACH with TUN is a topic for those familiar with the "slattach" bridge which predates tun, SlattachXtoTun is a tutorial by Maiko to present the differences in approach. Slattach is depricated in jnos2.0x[tbd].

Configuring the DOS IP stack The DOS platform does not establish it's own stack, therefore network devices to the outside world attach directly to jnos. NetDevDos tutorial shows network device handling.

ROUTING TRAFFIC thru WAN

In the topology above, routing was touched on for passing traffic to immediate neighbors, but routing has wide area application as well. Routing is a fairly complex subject made up of a few simple concepts. AX.25 traffic is subject to routing with tools: digipeating, NET/ROM. TCP/IP traffic is routed with tools: DNS, Static Route Table. Some automation is implemented in routing, but largely routing for 44... net is static and manual.

A TCP/IP class A network has been established for amateur radio use and is maintained by USC known as ampr.net [44...]. It is good practice to configure a host with ampr.net provided IP address. A general feature of the 44. IP address is that it is generally reachable only over RF paths, and only via encapsulation over Internet. Registration can normally be accomplished reasonably locally.

AX.25 cross port digipeating Packet traffic in AX.25 may be directed port-to-port as described in PortToPortDigi.

TCP/IP over RF Path TCP/IP traffic may be carried over a AX.25 path as described in RouteTcpIpRf.

TCP/IP over LAN TCP/IP traffic may be routed simply over network paths as shown in RouteTcpIpLan.

TCP/IP over WAN TCP/IP network for the 44... net may be carried over Internet as shown in RouteInternet44.

IP-in-UDP encapsulation A tool to keep the 44... net from mingling with the remainder of Internet is EncapIpInUdp which permits amateur traffic to pass over Internet paths without DNS resolution. The amateur community provides access to jnos hosts using static IP registered thru normal ISP sources and 44... registration thru ham sources.

CLIENT/SERVER SERVICES

Jnos uses the client-server model of operation to provide many user services. A list of servers found on a JNOS site may be found using the start command. The "start ?" command lists options compiled into the software when the executable is built. Additional servers such as DNS are built-in but not kicked off by 'start'. This section covers configuration requirements for all services.

APRS Server

Compile with #defined [tbd], configure per SetAprs tutorial, and enable with "start [tbd]".

AX25 BBS Server

To enable AX.25 network access to BBS services, compile with #defined [tbd], then configure per SetBbs tutorial, and enable with "start ax25". The AX.25 server is an integral component of the BBS. Each port (except hfdd ports) capable of AX.25 communication becomes a path to the BBS, plus after telnet server is started TCP/IP network also has access to BBS services.

Upon using packet to enter the jnos application, the login completes by placing the user in the set of BBS services. No distinction is made between AX.25 and TCP access to the bbs, the command set is the same.

HF server side, accepting connections from REMOTE stations (per Maiko) I have written a server side for JNOS 2.0 that will let you run a server on any of the HF ports. The only drawback is that once the server is running for a particular HF port, then that port can no longer be used to make outgoing connections, and you can not 'mbox kick' to forwarding partners that are configured for that particular HF port. This version of the server code has no 'stop' command at this time. The only way to break out of the server at this time is to restart the JNOS program. [tbd] To start the HF server on a particular HF port, use a command like this:

or alternavly like this:

You can put this command at the end of your AutoexecNosFile if you want.

CONVerse Server

Compile with #defined [tbd], configure per SetConv tutorial, and enable with "start [tbd]". [tbd] One example of a state-wide conference bridge is the configuration developed by MI-DRG as part of emergency response planning. Another is the work that Amateur Packet Radio Gateways has put into a world-wide conference network.

DNS Client/Server

Compile with #defined [tbd], configure per SetDns tutorial, and enable with "start [tbd]". [tbd]

FINGER User Information Server

Compile with #defined [tbd], configure per SetFinger tutorial, and enable with "start finger".

To enable the finger server so that others may query the users on your system, sysop must give the 'start finger' command. The finger files that provide information on a <username> are located by default in ./finger are ordinary ASCII files created by the sysop.

FTP Services

Compile with #defined [tbd], configure per SetFtp tutorial, and enable with "start [tbd]". [tbd]

HTTP Server

Compile with #defined [tbd], configure per SetHttp tutorial, and enable with "start [tbd]". More information on writing html documents can be found at: HELP

MAIL Forwarding Server

Compile with #defined [tbd], configure per SetForward tutorial, and enable with "start forward". This section deals with the intricacies of mail forwarding. Please read and understand this topic thoroughly before attempting to forward mail through your NOS box to the AX.25 BBS world, otherwise you might be the unhappy recipient of flames from other BBS sysops.

Mail Forwarding is an optional service for jnos. Mail forwarding may be a manual and or automatic function. There are two flavors of mail handling: one using FBB or F2B standards over RF paths, and one using SMTP and POP standards over RF and/or Internet pathx. This section focus is AX.25-based and excludes Internet services even though they have an impact.

One goal of this project is to see JNOS to JNOS forwarding over HF, using these new modes that I have added to JNOS 2.0. That's what I would really like to see in the end. If you want to arrange live HF testing with me, then please contact me, and let's try it out. Thank you. Any HF forwarding of mail and bulletins between this version of JNOS and any F6FBB system that I have tested with, has been almost flawless, and worked quite well to date. I'm very pleased with the results [VE4KLM].

AX.25 partner(s) in General This section does NOT deal with the minutiae of the mailbox and its various commands; it assumes that you understand concepts such as user areas (both public and private) and how to list and send mail. If you need help with these, please look elsewhere in the NOS docs. Apart from the usual DomainTxtFile and other files necessary for ordinary functionality of BBS, to move mail via AX.25 requires:

NOS AX.25 via hf The ForwardBbsFile content is similar to how they are defined for regular ax25 connects. The only real difference is that instead of using 'ax25' or 'c', you would use the 'h' command, ie:

Also, your RewriteFile may possibly have some entries specific to your forwarding partners. For example, in mine I have to have something similar to these below (if sp wu3v @ wu3v is to work).

WinLink 2000 telpac partners HF forwarding with AirMail? and WinLink systems is first developed for rev: jonos2.0e. To configure traffic with these HF systems see Maiko's tutorial JnosWl2kMail. Maiko and others successfully exchanged mail and bulletins with these systems on several occasions with earlier releases, but not consistently prior to releasing the HFDD device.

Scanning procedure The scanning process is initiated by [tbd] and the process is described in detail in FwdScanProc. The scanning process has been defined in Logic Map form as well:

Questions and Answers This is the beginning of a FAQ on the forwarding topic:

NET/ROM services

Compile with #defined [tbd], configure per SetNetRom tutorial, and enable with "start [tbd]". Originated in the 1980's with WA8DED and W6ISU, NET/ROM serves to extend and automate the reach of connect. Configuration tutorial SetNetRom configures AutoexecNosFile and the sysop continues with tuning of parameters that support netrom services. If local processing is desired, then configure netrom and 'start netrom' server to handle level 4 (transport) frames..

When NET/ROM is #defined at compile time, the 'attach netrom' command in AutoexecNosFile is often done so the frames are successfully recognised. It is common practice to permit jnos to pass net/rom frames at level 3 (network) even when no local process is involved at the application layer.

Manual entry of neighbors is done [tbd]

NET/ROM services may create a NetromSavFile file to preserve netrom nodes for later use. To create the file use netrom save and to restore the data use netrom load commands at the sysop console. The operations may be built into AutoexecNosFile and OnexitNosFile at administrator discression.

POP Mail services

Compile with #defined [tbd], configure per SetPop tutorial, and enable with "start [tbd]". Email may be delivered to network mail agents such as Evolution, mutt, and Internet Express, thru the POP server. In addition jnos supports a POP client that can fetch mail from remote POP servers on an ISP, or on a remote jnos server. Pop services are configured per SetPop and operated by various sysop or user actions.

REMOTE Services

Compile with #defined [tbd], configure per SetRemote tutorial, and enable with "start [tbd]". [tbd]

SMTP Client/Server

Compile with #defined [tbd], configure per SetSmtp tutorial, and enable with "start [tbd]". The client transmits mail out via TCP/IP and the server receives mail at the destination and places it into the mail queue. This is a one-hop prootocol. Mail over RF to a neighbor jnos node is the base configuration. Mail thru a gateway to Internet destinations is in tutorial MailFwdGate.

TELNET Server

Compile with #defined [tbd], configure per SetTelnet tutorial, and enable with "start [tbd]". The telnet server is an integral component of jnos. Upon using telnet to enter the jnos application, the telnet login completes by providing the owner with sysop services and other users with BBS services. No destinction is made between AX.25 and TCP access to the BBS, the command set is the same.

The "start telnet" enables access to JNOS. Each port capable of TCP/IP communication becomes a path for user access. [tbd]

TIP SESSION

Compile with #defined [tbd], configure per SetTip tutorial, and enable with "start [tbd]". [tbd]

ttylink Services

Compile with #defined [tbd], configure per SetTtylink tutorial, and enable with "start [tbd]". [tbd]

OPTIMIZATION STRATEGY

After a facility is working reliably, often it may be tuned for optimum performance. This requires vigilance using feedback mechanisms as conditions change, but over time parameters may be tweaked to arrive at a "best practice" performance compromise. [tbd]

Parameters to consider for tuning where default values may not be suitable and the measure of best fit are:

PARAM

EFFECTS

MEASURE

TxDelay

Transmission settle-in time

[V * 10]ms

Slottime

Wait for clear channel

Vms

Persist

Wait for clear channel - randomized

probability < V/255

maxframe

the max packet count combined for transmission

typically 4 (def = 1)

frack

Wait for ACK response time

seconds (def = 4)

tcp blimit

Number of added delays for retries to send a packet

iteration count

Optimum performance is measured by a maximum data thruput on the channel while at the same time minimum of retrys to pass data. The overhead of transmission delays and packet headers must be removed from the analysis. At this moment there appears to be no tool available for this measurement thus an optimum is rather subjective.

Of DATAGRAM and VIRTUAL CHANEL [VC]

Carrying TCP/IP traffic over an AX.25 network provided by amateur radio protocol requires some attention to tuning parameters. The command section provides detail, and the rule of thumb that VC shines on busy channels whereas DATAGRAM is preferred for clear channel use, establish a starting point for optimization. AxDataVsVc provides more detail usable for fine tuning.

Another recent experimental option in the mix is called AIP, it places IP directly over RF to reduce overhead involved for encapsulation. If and when this technology is accepted, it will provide another option for carrying IP traffic.

Of PACLEN, MTU, MSS, and More

Efficient creation of packets to carry TCP/IP over AX.25 requires some attention to configuration in order to optimize data flow. The TuneBufWin text originated from the JNOS40 Config Manaual written by Johan Reinalda and William Thompson c. 1994, and has been somewhat modified on this wiki. It is well to consider the page while tuning performance.

IRTT, TIMERTYPE, RETRIES, a Watchful Eye

What every sysop should know well and watch for is communication efficiency. Only the sysop can change the configuration to make efficiency better, and the result should be happier users. The interplay between setup values and performance for secure communication is the subject of TuneIrttAck and the task of tuning may take quite some time to make "good", and as the network changes over time so will the configuration.

DATA COMPRESSION

Data encryption is generally not permitted, but data compression may be used to reduce the volume of data flowing across a port. If both ends of a data path can support compression then the feature may be enabled to enhance data thruput. The DataCompress tutorial shows how to implement the feature for ascii data.

TROUBLESHOOTING

THE BEST BUG IS THE ONE THAT NEVER HAPPENS. In many cases, results that look like unexpected bugs are a consequence of mis-configuration. Jnos has a long and stable history, yet it also includes troubleshooting aids for the user and owner.

BUG AVOIDANCE

Over the life of jnos, at any revision level certain steps were taken to avoid bugs and/or work around issues planned for change. For this wiki, application notes are collected here for consideration.

For 2005 thru 2006 two bug avoidance specials follow...

  1. Disable beacon on HF to avert bug known in 2005 / repaired per jnos2.0e. Insert the following commands into AutoexecNosFile after defining the ptcpro device. 

ax25 bcport ptcpro off
mbox mport ptcpro off

  1. Set APRS - specify APRS ID to avoid crash from bug repaied per jnos2.0d#? Insert the following command into AutoexecNosFile after setting the station ID. 

aprs logon call k8rra

Routing Debug Toolkit

For the process of fixing broken routes, various tools are handy. Tracing activity on I/O ports is available. Use the jnos sysop command "trace" to start and stop tracing on screen or data may be archived to file. On a Linux host, the "tcpdump" command captures activity on the host stack and can also display live or archive data on file. The "ping" command on both jnos and the host measure round trip time for echo packets to the remote host and back. Ping syntax and operation is somewhat different when used on the host command line, used from the BBS, and used as a sysop command. The jnos "hop check" and Linux host "trace route" commands display the route used for communication to remote nodes.

HostConfiguration (last edited 2008-04-11 17:10:50 by GeorgeVerDuin)