NOSaprs 1.15b6

 

APRS Server & Internet Gateway for TNOS and JNOS

 

Designed & Coded by Maiko Langelaar, VE4KLM

during the period of April 2001 to July 2003

 

Saturday, July 12, 2003

 

 

Table of Contents

 

Title page                                                                                              1

Table of contents (this page)                                                                   2

What is NOSaprs                                                                                   3

Why did I write this software                                                                   3

Some of the features                                                                              3

General overview (how does it work)                                                         4

What does NOSaprs hear                                                                       4

Most of the NOSaprs commands (very detailed descriptions)                     5

Starting the services                                                                               16

Setting the unproto path (very important)                                                  16

Understanding routing - by message recipient                                           16

Understanding routing - by which interface station was last heard on          16

How RF users can opt out of the internet gateway                                     17

Email Server – RF users can send email via APRS                                   17

The APRS Message Center (a simple messaging client)                           17

Tracking APRS stations – the APRS heard table                                      18

Status information – using the tcp/ip finger utility                                      18

Status information – via port 14501 and a web browser                              19

How to setup the NOS configuration file - autoexec.nos                             20

Miscellaneous stuff and other notes                                                         22
What is NOSaprs

 

NOSaprs is an APRS internet gateway (igate) and server integrated into NOS itself. Those that are already running JNOS or TNOS internet gateways can easily start to support their local APRS community by simply getting a NOS binary that contains the NOSaprs services, and then adding a few extra lines to the autoexec.nos file. Use an existing RF port (zoo channel), add another port and radio for 144.390, add multiple RF ports on different frequencies, use a 9600 baud port, use AXIP or AXUDP to get APRS data from other internet gateways around the world, do whatever you think is possible with your NOS setup.

 

Why did I write this

 

First of all, this software is in no way meant to compete with other APRS software that is out there. There is some very impressive software available that is dedicated to APRS, in particular UI-View, which impresses the heck out of me. I wrote this specifically for the NOS community - the NOS die-hards if I may – allowing them to participate in the APRS world wide experience without the need to setup extra and possibly separate systems that may or may not easily fit into their existing configuration.

 

If you try this software, and in the end you don’t like it, or you don’t want to use it, that’s perfectly fine by me, at least by then I hope you will have gained some insite and good experiences with APRS in general.

 

Some of the Features

 

·         Intercepts most APRS data heard on any NOS ax25 interfaces, and forwards the data to the APRS internet system, which in turn allows the data to appear on the maps of APRS client software throughout the world, as well on internet APRS databases like the popular www.findu.com site.

 

·         Allows APRS users on any NOS ax25 interface, to exchange messages with other APRS users on remote APRS networks only reachable through the APRS internet system, using the 3rd party messaging system.

 

·         Powerfull callsign filters – currently there are five (5) filters available for a variety of operations.

 

·         Tracks APRS users heard on all NOS ax25 interfaces. The system can track callsign, DTI, which ax25 interface the frame was heard on, and the unproto (digi) path of the frame if any digis were used. This information is available using finger aprsstat@machine or by web browser using http://machine:14501.

 

·         When forwarding APRS data to the APRS internet system, a Point of Entry (POE) callsign is inserted into the source path header, allowing other systems to identify your machine as the one which injected the APRS packets into the APRS internet system. This can be disabled by the sysop if desired.

 

·         Intercepts MIC-E packets and forwards them to the APRS internet system (extra options available).

 

·         Supports routing by message recipient, allowing APRS users on conventional packet networks to participate in the APRS scheme of things. Users several nodes away can now join in on the APRS fun without the need for WIDE, or RELAY, or APRS digipeaters.

 

·         APRS Email Server. Email can be handled locally by NOS itself, instead of being sent out to the APRS internet system for processing. Any APRS user can send internet email, simply by sending an APRS message to the recipient callsign, ‘EMAIL’ (extra options available)

 

·         APRS users can opt out of the IGATE by specifying RFONLY or NOGATE in the unproto path, that way their packets are not forwarded to the APRS internet system.

 

·         APRS message center – messaging client - allowing the NOS sysop, and the general PBBS user, to do message passing with any other APRS user, either on a remote APRS network only reachable through the APRS internet system, or through one of the NOS ax25 interfaces for local message passing. This was designed to have a somewhat convers type of look and feel - some restrictions apply.

 

·         An HTML based status page, similar in concept to what aprsd provides, using tpc port 14501. A sample screen shot of this HTML based page, is shown on the opening page of this documentation. A text based version is also available using the tcp/ip ‘finger’ utility. See the ‘Tracks APRS users’ feature mentioned earlier on this page. Users can click on callsigns on this page, and get a direct link to mapping information from sites like the popular www.findu.com site.

 

·         Flexible broadcast options. NOSaprs has separate broadcast parameters for the internet side and the RF side. Each side has it’s own set of parameters, in which you can configure the broadcast interval, status text, and position information. If you don’t want broadcasts at all, they can be shutoff if desired.

 

·         Responds to ?PING? or ?APRST requests from APRS internet system and from the RF side. You can also send a message to NOSaprs, which is logged to a file (ie, /nos/spool/aprs/aprs.txt). All messages to and from NOSaprs logon callsign are logged (including sysop and PBBS message center traffic).

 

·         Accept's connections from other programs like UI-View, WINaprs, and other NOSaprs stations so that they can forward APRS data to us and not get the firehose of data sent back to them.This is also ideal for those systems that have very low speed (or low bandwidth) connections, and simply want to advertise their position and other information to the world and not hear back from the world.

 

·         Experimental WIDE and WIDEn-N digipeater built in (can be switched on or off on the fly).

 

·         Can broadcast to RF, specific position and status packets received from the APRS internet system, not just APRS messages anymore. All broadcasts use the 3rd party identifier to stay legal.

 

·         Other features are added as time permits.

 

General Overview (how does it work)

 

The NOSaprs software has the minimum functionality required to be an APRS internet gateway (igate), so it should be configured to connect to tcp port 1314 (the message port) of any aprsd or java aprs server that is part of the APRS internet system. At startup time, NOSaprs will go through a list of servers, connecting to the first one it can. Once connected, it will continuously receive messages from the server, and route those messages out a preconfigured NOS ax25 interface. There are callsign filters available so that the sysop can control which messages are allowed to go out, and which are not. APRS frames received on any NOS ax25 interface are sent to the APRS internet system, using the same connection we receive messages on. Keep in mind that NOSaprs only connects to 1 host server at any time, unlike other APRS servers that can be configured for multiple connections to different host servers, for the sake of redundancy, etc. NOSaprs can also take positional and status information from the APRS internet system and broadcast them out the preconfigured NOS ax25 interface. There are callsign filters available to control this aspect as well.

 

I strongly recommend you go over the NOSaprs commands further on in this document, to get the best understanding for how this stuff works. The commands are quite well documented, and I have gone into some fairly heavy detail, including extra information on the mechanics of how all this stuff is supposed to work. If I have missed anything, or something does not look right, please let me know so I can correct it.

 

What does NOSaprs hear

 

NOSaprs will hear any APRS packets that have a destination call of ‘BEACON’, ‘ID’, ‘EMAIL’, or any callsign starting with the letters ‘AP’, or any callsign that matches the APRS MIC-E callsign requirement. The number of digipeaters in the packet header, or whether any of the digipeaters were used to repeat the packets, is of no importance. NOSaprs will hear it all, and process it accordingly. I have fairly strong validation rules in place, so not everything heard is sent to the APRS internet system. For example, 3rd party packets heard on any of the NOS ax25 ports, are NOT forwarded to the internet system, since they’re not supposed to be.

 

Most of the NOSaprs commands

 

Most of  the NOS commands related to NOSaprs start with the word ‘aprs’ and are as follows.

 

1.0        aprs <subcommand>

 

The current subcommands can be obtained by entering the command, ‘aprs’, at the NOS prompt :

 

Net> aprs

valid subcommands:

  bc        flags     calls     client    contact   hsize     interface

  internal  listen    locator   log       logon     server    email

  mice      status

Net>

 

Next we will summarize the above commands, from left to right, top to bottom …

 

1.0.1          aprs bc …

 

NOSaprs broadcasts it’s own status and position information at regular intervals. There are two groups of broadcasts, one to RF, the other to the APRS internet system - they are independent of each other. Use these commands to configure the content of these broadcasts, and whether you want them active or not.

 

Net> aprs bc

Usage: aprs bc [ver|rfver] [on|off]

       aprs bc [stat|pos|rfstat|rfpos] [data]

       aprs bc [timer|rftimer] [minutes]

Net>

 

1.0.1.1  aprs bc [stat | pos | rfstat | rfpos] [status or position text]

 

This command lets you set the text of the status and position information that you want broadcast by the NOSaprs server. There are four possible options here :

 

stat   - status text to be broadcast to the APRS internet system side.

pos    - position text to be broadcast to the APRS internet system side.

rfstat - status text to be sent out the default ax25 interface side.

rfpos  - position text to be sent out the default ax25 interface side.

 

If  you want the same text broadcast to both the APRS internet system side and RF, then you only need to define the stat and pos options. If the rfstat and rfpos options are not defined, they will default to the values set for the stat and pos options. For example :

 

aprs bc stat "IGATE - 441.050 Mhz - ve4klm@ve4umr.ampr.org"

aprs bc pos "4953.22NI09718.35W&"

 

I now use ‘=’ as the dti (Data Type Identifier) for the position broadcasts (since NOSaprs is capable of messaging), so make sure you do not change the format of the above information. Only change the numerical coordinates - degrees, not decimal - to suit your own position. By default, the status text above will have the NOSaprs version prepended to it when it is broadcast, so in actually fact the broadcast will look like the following :

 

NOSaprs 1.15b6 IGATE - 441.050 Mhz - ve4klm@ve4umr.ampr.org

 

You can switch this suffix off using the command, ‘aprs bc ver | rfver’, described a bit further on.

 

1.0.1.2    aprs bc [timer | rftimer] [interval in minutes]

 

This command lets you set the interval of the status and position broadcasts. The RF broadcast has it’s own timer, as does the APRS internet system broadcasts. If you don’t want a particular broadcast, then either set the interval to the value of zero, or don’t define the timer(s) in the autoexec.nos file. By default, the timers are off.

 

1.0.1.3    aprs bc [ver | rfver] [on | off]

 

This command simply flags whether you want the NOSaprs version information prepended to the status broadcast(s) or not. The RF broadcast has it’s own flag setting, as does the APRS internet system broadcast. By default, the version is included in the status broadcast.

 

1.0.2          aprs flags …

 

NOSaprs uses flags for some of it’s configuration. You can enter the command, ‘aprs flags’ at the NOS prompt, and it will show you the current settings (the ones below are the default flags) :

 

Net> aprs flags

-debug -badpackets -monitor +poe +dtiheard +bconlyifhrd -digi

Net>

 

Flags are set using the command, ‘aprs flags +option’ , and unset using the command, ‘aprs flags –option’.

 

Next we will describe each of the availabe options in detail.

 

1.0.2.1    debug

 

If you run into problems and are lucky enough to be able to reproduce the problems, then you can enable the debug option, which will write additional debug or trace information to the NOSaprs log file.

 

1.0.2.2    badpackets

 

If you want to track parsing errors, or want to know about APRS frames that had errors in them or did not meet some requirement of the general APRS specification, then you can enable the badpacket option, which will write error messages to the NOSaprs log for any packets that have formating issues.

 

1.0.2.3    monitor

 

If you want to monitor the exact data you are receiving from the internet side, you can eable the monitor option. This is simply an extension to the debug facilities. Be careful with this option, as the information is currently dumped to the NOSaprs log file. If the internet traffic is high, the log file will fill up really fast.

 

1.0.2.4    poe

 

This option is used to enable or disable the injection of the Point of Entry (POE) callsign into the source path header when forwarding packets to the APRS internet system. By default, the POE is turned on. It can be switched off of course, but there really is no reason to do so. The injection of the POE callsign allows one to trace which APRS igate was responsible for sending the APRS packet to the APRS internet system.

 

1.0.2.5    dtiheard

 

Allows the sysop to enable or disable tracking of the DTI (Data Type Identifier) character in the APRS heard table (not the same as the ax25 heard table). The APRS heard table can get quite big if we get the same station using a whole bunch of different DTI values (meaning an assortment of different type of APRS packets). Quite frankly, there is no point tracking the DTI for general use. I use it to get an idea of the type of traffic on frequency, and some of you may want to do the same. If this flag is enabled, then the 14501 pages will show the DTI information. If this flag is not set, the you will not see the DTI information displayed on the 14501 page.

 

1.0.2.6    bconlyifhrd

 

The purpose of this flag is to minimize the amount of RF traffic generated by the APRS internet gateway. I mean, what is the point of broadcasting a 3rd party message from the APRS internet system to RF if the station for which the message is intended was never heard within range of the NOSaprs server. Some people will have different views and preferences of course, that’s why this flag was added. By default, this flag is set, and it only applies to APRS messaging.

 

If this flag is not set, then of course NOSaprs will send the message out the interface on which the message recipient (station) was last heard. If the station was not heard, then the message is sent out the default aprs interface, which is configured with the command, ‘aprs interface’, discussed further on.

 

Note : this flag does not affect the callsign filters in any way. All it does is limit RF transmissions !

 

1.0.2.7    digi

 

NOSaprs has a very experimental built-in APRS digipeater. It can digipeat WIDE and WIDEn-N packets, and will track for duplicates, so there should be none of this endless bouncing back and forth of packets between NOS and other digipeaters on frequency. This option should only be used if you have no other APRS digipeater in your area, and you want to provide an interim or emergency digipeater. I’m willing to work on this some more, but only if people express an actual interest in it.

 

By default this flag is unset. I recommend you leave it that way if you are in a well established APRS arena.

 

1.0.3          aprs calls …

 

NOSaprs has a series of callsign and ‘callsign pattern’ filters to deal with different areas of functionality.

 

Net> aprs calls

Usage: aprs calls [fwdtorf|bantorf|ignorerf|postorf|stattorf] *[callsign &| patt

ern list]

Net>

 

These are very powerful commands, so be very carefull on how you implement them. You can run these command on the fly for all the available filters, so subsequent instances of any command will simply delete the existing filter, and create a new one to replace it. Also, note that the wildcard feature detailed in the fwdtorf section applies to all of the available filters (very powerful indeed).

 

There are currently five (5) filters available to the sysop. Next we will go over each of them in detail …

 

1.0.3.1    fwdtorf

 

This filter is specific to APRS messaging and broadcasting of 3rd party messages. It allows the sysop to configure which messages from the APRS internet system are allowed to go out the RF interface. The filter looks at the recipient callsign of the message to determine if it goes out RF or not. The best way to show this is by example, for instance take a look at the following :

 

aprs calls fwdtorf ve va k*6 k*4k