Version 0.73 (Beta)

A cross-port AX.25 L2 Smart Digipeater program and NET/ROM Node

 for the SV2AGW’s AGW Packet Engine

by Ing. Pedro E. Colla (LU7DID)

[email protected]

Adrogue – Buenos Aires - Argentina




Table of Contents


Abstract 2

What is this program for? Audience. 3

Installation. 5

Pre-Requisites. 6

Verification. 6

Functional Description. 7

Configuration File (DIGIPLEX.INI) 8

Interface Configuration. 14

Connection Security Configuration. 15

SMART Directive. 16

ROUTER Directive. 16


Usage. 17

Distributing Resources. 17

“Normal” Mode. 18

APRS Compatibility Mode. 19

Layer 3 NET/ROM Router 21

NET/ROM Router 21

NET/ROM Router Configuration. 22

NET/ROM Managed Applications. 23

NETROM Nodes Block. 23

INP3 Compatibility. 24

NETROM Improvements. 24

Digiplex Internode Protocol 25

NETROM Tunneling (SMART Mode) 25

MHEARD Router 26

HTTPd Server 26

Installation of the Web Interface. 26

Content Management 27

Smart Mode. 27

Functional Description. 28

Command Line Interface (CLI) 28

Configuration. 30

CLI Security. 30

Splash File (Welcome.INF) 31

Other Text Files (*.INF) 31

Command Reference. 31

A Command. 31

P Command. 32

J Command. 32

N Command. 33

N with no arguments. 33

N *. 33


R Command. 35

L Command. 35

U Command. 35

C Command. 36

V Command. 37

DATE Command. 37

I Command. 37

SYS Command. 38

LOGIN Command. 39

Command Line Interface Aliases. 39

FlexNet Compatibility. 40

Troubleshooting. 40

Can not establish communication with AGWPE. 40

Does not operates correctly as a digipeater 41

A Defined Listener doesn’t seems to work. 41

Digiplex and the AR DX Cluster 41

Throughput of the digipeating process is slow.. 42

The GUI dialog appears right on Start, Nothing seems to Work. 42

Failure to interact with a NETROM node delivering CTEXT. 42

Discussion of the Program Modes. 43

Suitability of a Wintel Box to operate as an Infrastructure resource. 44

Known Bugs & Pending. 46

Acknowledgements. 46

Version Information. 47

Disclaimer and License Statement 50





DIGIPLEX[1] is a Windows 95/98/NT/ME/2000 executable implementing a cross port AX.25 Layer 2 Smart Repeater (Digipeater) for the AGW Packet Engineâ. a 32 bits AX.25 packet platform developed by George Rossopoulos (SV2AGW).


It’s purpose is to enable a given station to act as a digipeater either on traffic over a single AGWPE defined port or across different radio ports (frecuencies).


AX.25 frames heard in one defined port indicating the callsign of the digipeater as a path will be transferred to the other defined port as a digipeated frame and viceversa in a way that enables a full two-way packet contact across (eventually) different ports.


It is intended to enable the communication of stations operating on different AX.25 radio channels (at even different speeds) in a transparent way just by routing the a given connection over the digipeater program, in other words, the program could be seen as a simple AX.25 Layer 2 router or switch.


Since the operation is fully transparent any kind of contact is supported, including network protocols such as NET/ROM or FlexNet as well as TCP/IP.


The program could be used also as a Layer 3 Router capable to operate with the NET/ROM protocol both to achieve enhanced digipeater functions and to interact with neighboor NET/ROM nodes.


DIGIPLEX uses the newly available TCP/IP API of AGWPE (WinSock API) and should run on any machine AGWPE could run, you could download the latest version of the program as well as the TCP/IP API related documentation directly from George’s home page at http://www.raag.org/sv2agw or http://www.elcom.gr/sv2agw .



What is this program for? Audience.


Many packet operators are familiar with the concept of an AX.25 digipeater since this is a feature built into the AX.25 protocol itself and since forever.


A digipeater is a simplex, digital, repeater which relay AX.25 frames between stations; several digipeaters could be chained (into what is known usually as the “VIA” path), it has many uses being the most obvious ones to extend the coverage of a given station or to take opportunity of the privileged position of a particular station to extend the useful range of a given station.


The digipeater concept is very simple and it’s also simple to setup and operate one, actually many regular stations has their software or hardware configured in a way that could operate as a repeater (the setup is far more simpler than the one required for the distant cousin, a voice/digital duplex repeater).


As simple as it is a digipeater has it’s drawbacks also, the most obvious is the efficiency in terms of bandwidth (or effective throughput speed) if you wish.


Since the frames are relayed entirely every digipeater “hop” reduces the bandwidth efficiency (and thus the throughput) by half, making impractical links over more than 2 or three hops (albeit the protocol itself allows several more hops); this single factor has reduced the actual usability of digipeaters very much and when greater distances or coverage is required more advanced routing techniques (operating at Layer 3 or 4 such as NETROM or TCP/IP) are favoured.


In practice is very rare to see usages of more than one hop except on very special situations and geographic configurations.


Still, with the proliferation of stations with more than one radio port the desire (or need) for an station operating on one port (radio channel) to hop over and link with an station in another channel do appear.


In order to achieve that trick, beyond the scope of a simple Layer 2 digipeater which operates on the same channel, more complex setups are usually required, such as an AX.25 switch (like G8BPQ) or other Layer3 and 4 implementations such as NET/ROM  or FlexNet.


When more complex configurations than a simple-hop router are needed the program implements also other schemes for transport and routing such as an implementation of the  NET/ROM protocol and a simple MHEARD based routing scheme.


This program takes advantage of the multiport nature of the AGW Packet Engine to implement a Layer 2 digipeater with some additional (optional) features, in particular the capability to relay frames from one radio port to other in a bidirectional way.


Then, stations operating at one radio channel could “transparently” link with stations operating in another.


Nothing prevent this program to be chained across “several” channel “hops” as long as (of course) there are stations running it that could create such a route.


To operate using a digipeater over more than one channel is not as inefficient as to do the same on the same channel, the bandwidth is used once on each channel; still the throughput will reflect the fact the frame is transmitted twice (or more).


It’s ideally suited to link channels where the speed is different (i.e. 1K2 and 9K6) when the throughput effect for the slower side is much less important, few issues has to be addressed and understood in order to optimize such setup (some of the issues are covered in detail later in this document).


Actually, nothing prevents to implement special configurations such as two channels on different geographical regions linked by a dedicated (high speed) link; still the routing has to be made manually (stating the digipeaters of both ends of the high speed link).


The audience of this program should be composed by anybody willing to experiment a little; more stable setups should be performed by stations that having a multiport configuration and relatively good equipment (or geo location) are willing to provide a connectivity service to their neighboors.


Some provisions has been made to make this program compatible with APRS (A Packet Radio System), additional information could be found on the appropriate section of this document (see APRS Compatibility Mode ).




Warning - Notice


There are operating considerations when you use the digipeater across ports that works at different speeds. Please refer to the operation instructions before to implement that configuration.



To install the program the following actions has to be performed:



where nnn.nnn.nnn.nnn is the IP Address of the machine where AGWPE is running (you could check which is the machine’s IP address with the Windows’s WINIPCFG utility).

If you don’t know the IP Address and AGWPE is running on the same machine you could try with IP_ADDRESS= (see the Troubleshooting section for further details).



where XXXXXX is the callsign of the digipeater and nn it’s SSID (i.e. LU7DID-1), be sure the callsign-ssid you assign to the digipeater is not currently registered by any other application program running under AGWPE (check it with About/WinSockets on the AGWPE menu).




One entry in the form

{Interface Name}={AGWPE Port},{CallSign},{Alias}.{Quality},{.. flags}

Per repeater listener required

(i.e. ax1=1,LU7DID-1,,250,ROUTER,APRS,TCP,SMART)


Many other options might be required to enable or configure different aspects of the program operating behaviour, please see the appropriate sections of this manual for details.

The program doesn’t alter any system resource nor configuration, it could be removed just deleting the directory where it had been installed or by executing the automatically installed Uninstall program.







The AGWPE version required is 2001.10+ or later, it could work with versions starting with 2000.10+ (it won’t work with versions prior to that), so if you have a prior version or you are not sure what version you have just play safe and download a fresh version from SV2AGW’s Home Page



AGWPE versions prior to 2001.22 have a bug called “sleepy frame problem” where erratically links

got stuck and eventually reset due to lack of activity; essentially frames sent by Digiplex were held

inside AGWPE without being transmitted. This problem severely impairs the activity as node and

file transfers (such as BBS forwarding). Usage of AGWPE 2001.22+ is highly encouraged.








When used with versions prior to 2001.10+ (but higher than 2000.10+) some incompatibilities on the NET/ROM operation will be found, other functions of the program will not be affected.


The AGWPE has to have at least one loopback port defined for this program to work.


The program itself could run on either Windows 95, Windows 98, Windows NT, Windows 2000 and (probably) on Windows ME, still, the main requisite is to have AGWPE up and running on the target platform you’re planning to use.


*** Important Notice ****


DIGIPLEX interacts with AGWPE using it’s TCP/IP API, that requires the Windows 95/98/NT TCP/IP stack to be configured and functional. However, this is not related to the AGWPE TCP/IP drivers (for Windows 95/98) which are essentially a way to allow the Windows TCP/IP stack to operate over AX.25 radio links, the AGWPE TCP/IP drivers do not need to be installed for DIGIPLEX  to work properly. Beware that the AGWPE TCP/IP drivers requires registration to work after a trial period, for details about the registration please see George’s (SV2AGW) Home Page.

There is one operational mode of this program that MIGHT require the AGWPE TCP/IP drivers to be installed, and it is when you enable the “worm” mode on a given listener and wish to carry the connection over radio. The drivers are not required if you want to use the worm mode over other TCP/IP connections such as over the Internet.




The DIGIPLEX  is an application that could not be accessed directly by the user other than to shutdown it, it has to be loaded initially and furthermore it will operate over the frames heard on the designated ports without the operator intervention.


·        Load and configure AGWPE, follow the intallation instructions for that. Be sure the AGWPE.INI file has the following entry




·        Ensure at least one Loopback port is defined, this program will not work without it.

·        Turn off the AGWPE Security, it won’t be required unless your system is open to big networks and you could configure it later. To do so go to AGWPE Setup Interfaces/Winsock Interface Security and select the radio button “Accept without Login from Anywhere”.

·        Test AGWPE to be functional with any of the provided programs such as AGWTerminal or AGWMonitor, if they refuses to work it’s highly likely that DIGIPLEX won’t work either.

·        Load DIGIPLEX, it should work transparently. In case of problems see the Troubleshooting section of this document.




Functional Description


The DIGIPLEX program is an AGWPE compliant application program which implements an AX.25 Layer 2 Repeater (Digipeater) as it’s core functionality.

The program inspect the traffic over the defined ports of each listener[2] defined ([INTERFACE] Section) and whenever it detects frames that has been informed the callsign-ssid of the associated listener  as a part of the path it performs the following activities:

·        It sets the “Repeated Bit” to 1 on the AX.25 Frame.

·        It resends the frame thru the interface owned by the callsign-ssid referred on the AX.25 frame (SSID routing).


An AX.25 Layer 2 Repeater (Digipeater) is a relatively dumb device, it doesn’t handle the concept of a connection nor manage any detail about the handshake between both final ends of the connection (that might include, albeit not necessarily, other digipeaters in the path); as many frames are heard that fits the relatively narrow criteria already stated are re-broadcasted.

Since the digipeater knows nothing about the nature of the connection it could handle any sort of traffic, both connected and unconnected frames; also, it could handle special frames such as the ones typically used for NETROM or TCP/IP traffic.

Whether or not the digipeater rebroadcast a given frame is strictly defined for the detection of it’s own callsign-ssid (as defined on the entry of the INTERFACE section on the DIGIPLEX.INI configuration file) with the “Repeated Bit” of the AX.25 set to 0 (not repeated yet) and with no other digipeater stated on the frame with that bit also set to 0 (meaning that the digipeater is “hearing” a frame that has not been “digipeated” yet on the proper sequence).

Other operating modes are also available (see “Smart” Mode ).


Configuration File (DIGIPLEX.INI)


The most basic and primitive configuration needed by DIGIPLEX  has been set with the short instructions given for the initial installation of the program, however some additional operation modes and configuration parameters should be stated as well.


This file is not used for any other program nor affects in any way the overall behaviour nor the operation of the Windows environment, it could be removed as a part of the uninstallation of DIGIPLEX  program withour any further consideration.


However, if not properly configured it is unlikely that DIGIPLEX could work at all (and in some cases it would drive it to fail, see Troubleshooting for details), so attention has to be pay to the settings defined on it; also some undesired “on the air” behaviour could be obtained if some parameters are improperly configured.


The overall format is that of any standard Windows .INI file,  several section logically groups the configuration parameters of different aspects of the program as follows:




[DIGIPLEX] Section



Defines the IP address of the machine where AGWPE will be found (default



Defines the TCP port used to communicate with AGWPE (default 8000).


This is an interim configuration parameter that when stated as DEBUG=YES direct DIGIPLEX to generate traces of its internal activity on the DIGIPLEX.LOG.In order to disable the logging the line has to be set as DEBUG=NO or removed from the DIGIPLEX.INI file.



This is a parameter {1 to 5} that defines how detailed the events logged will be, 1 being the least and 5 the highest, there should be no reason to set this parameter on values different than 1 unless a need to trace and debug exists.

Warning: once the traces are activated the logfile generated could become quite large (dozens of megabytes!!).


This is the CallSign+SSID the program will use to communicate with AGWPE. Not necessarily be a digipeater CallSign-SSID (Unless also stated in the LISTENER sections).


This is the hostname of the machine where AGWPE is running; this parameter is optional but if indicated takes precedence over the IP_ADDRESS parameter. The hostname has to be successfully resolved either by the DNS server or thru an entry in the HOSTS file for the connection to take place..


Valid for users with AGWPE 2000.78 or higher

If the machine running AGWPE has a security setup that excludes the machine from where the program is being run a login has to be made using a valid and defined UserId/Password (as defined at AGWPE). This parameter sets the UserId to be used for that validation.

This userid will be used for all connections started from the digiplex program with the AGWPE (API connections, not AX.25 connections).



Valid for users with AGWPE 2000.78 or higher

Same as the LOGIN parameter but for the Password to be used in the login process.



Try to recover if initial attempt to connect to AGWPE fails, default NOT.


Password that will be required for the sysop to Login into the node and have access to the SYS command.


Only required if Beacon Desired


ID where the frames of the beacon will be sent, the beacon is optional and not related with the operation of the program as a digipeater. It only helps to make it presence visible to others on the channels.

If more than one CallSign-SSID is indicated (separated by blanks) the first is considered the “destination” while the remaining the VIA path.

The beacon is sent thru ALL the defined AGWPE ports.


Text to sent thru the beacon


Elapsed in mSecs between successive broadcasts of the beacon (0 will disable the beacon).


If YES a list of all L2 Digi callsigns and serviced ports is added to each broadcasted beacon message.



One entry per listener in the general format



Name is any user choosen name to refer to the interface

Please do note the double ,, between the CALLSIGN-SSID and the optional tokens.

A verification is made to avoid conflicting definitions,

the APRS token is optional and enables the operation of the digipeater in APRS compatibility mode.

The SMART token activates an special hop-to-hop ack protocol across the digi.

The ROUTER token activates router functions on the interface

[APRS] Section

Optional (only if APRS compatibility is desired)


Comma separated list of all APRS destinations accepted by the digipeater in APRS compatibility mode (ej. WIDE,NARROW).


Indicates whether Alias replacement takes place (YES) or don’t (NOT or not informed).


Indicates whether UI frames only are allowed on APRS compatibility mode.


Activates (YES) or deactivates (NOT or not informed) the WIDEN-N multihop APRS mode.


Activates (YES) or deactivates (NOT or not informed) the TRACEN-N multihop APRS mode.


Indicates the destination id to be used for the WIDEN-N mode (default WIDE)


Indicates the destination id to be used for the TRACEN-N mode (default TRACE)

[APRS_ALIAS] Section

Optional (only if APRS compatibility is desired)


If SUBALIAS=YES this section list all substitution to take place when in APRS compatibility mode.

[ROUTER] Section

Optional (only if Layer 3 Routing is desired)


Defines whether or not Layer 3 Routing is Enabled or Not


Defines whether or not Layer 3 Routing is Enabled or Not


Defines whether or not simple MHEARD based routing is Enabled or not.


Defines the master cycle time for broadcast routes and nodes information (in milliisecs).


Defines the Router default Alias to be used.


Digiplex saves it routes (ROUTES.INI) every MASTER cycle, in case of a restart it will start building routes to neighbors from stratch (NOT) or will start from the last snapshot it took (YES)


Select the file where routes will be saved, ROUTES.INI by default.


Includes (YES) or doesn’t includes (NOT) the timeout value on NETROM SABM frames (default YES).

[NETROM] Section

Optional (only if Layer 3 Routing is desired)


Minimum Quality accepted for Broadcasts


Default Quality


Minimum Obsolecense accepted for Broadcasts


Obsolecense set initially


Default Quality to be assigned to Managed Applications.


Maximum number of frames sent during a L3 Broadcast.


Timeout for L4 sessions (in mSecs)


Maximum window to be used during L4 sessions


Default Quality assigned to NETROM Managed Applications


Maximum Network Horizon


Default RTT (msecs)


Interval for RTT meassurement (in msecs)


Enable generation of compressed NETROM frames


INP3 Compatibility mode (default YES), see NETROM Improvements


Optional, see NETROM Nodes Block


Optional, see NET/ROM Managed Applications

[HTTP] Section

Optional, See HTTPd Server

[CLI] Section

See Command Line Interface (CLI)

[CLI.ALIAS] Section

Optional, See Command Line Interface Aliases



If the DIGIPLEX.INI file can not be found the default values are used by the program, however those defaults might or might be not appropriate to your particular configuration. Since the file is a normal ASCII file it could be edited with any text editor such as Windows’s Notepad or Edit.


Follows a sample of the DIGIPLEX.INI which is being used for on-the-air tests of the program (included in the distribution file).





















TEXT==3448.00S/05823.90W-APRS *145.15/431.20 LU7DID-1 (Adrogue,BA,Argentina) *




















































DXC=C 4 LU7DID-3,DX Cluster

DOS=T lu7did,Telnet to LU7DID Radio Box

XNET=C 4 LU7DID-4,(X)Net Router

TELNET=C 4 TNCLI,Telnet Manager

DXC=C 4 LU7DID-3,DX-Cluster












QTH=Adrogue,BA,Argentina [GF05TE]



Interface Configuration


The program uses the concept of a listener or Interface or port, each port behaves as a different digipeater for all practical purposes, so cross-activity is allowed between all ports for whom an interface had been defined.


The overall format of the entries at the INTERFACE section (one entry per listener) is as follows:


{Interface Name}={Port},{CALLSIGN-SSID},{ALIAS},{Quality},[Optional Directives]


All interfaces verifies the traffic on all AGWPE ports but only digipeats on the one it owns.


Please note the ALIAS is not longer functional for any purpose (should be coded as two consecutive commas) while the CALLSIGN-SSID differentiated by port is still needed but for digipeating functions NOT for the NETROM router.


So a request to digipeat a frame on any port thru any of the defined listeners will make that listener to perform the actual digipeat of the frame over the port it owns, the frame is manipulated in order to reflect it’s source as been the listener on the port it was heard enabling the backward path to be used.



The [INTERFACE] section states





In this configuration the port 1 is owned by LU7DID-1 while the port 2 is owned by LU7DID-2


When the frame


2: Fm: LU9DGN To: LU3DY via LU7DID-1 <SABM>


is heard, it’s on the port owned by LU7DID-2 (port 2) but addressed to the listener on port 1 (LU7DID-1) so it will be digipeated thru port 1 as follows:


1: Fm: LU9DGN To: LU3DY via LU7DID-2* <SABM>


Please note that the frame has been altered in order to reflect the path any answer to it has to follow, actually, when the other end answers:


1: Fm: LU3DY To: LU9DGN via LU7DID-2 <UA>


The inverse process takes place and the frame is digipeated as:


2: Fm: LU3DY To: LU9DGN via LU7DID-1* <UA>


Please note that if the callsign-ssid of the listener matches the port it owns the digipeater repeats the frame over the same channel, as in the following example sequence:


2: Fm: LU9DGN To: LU3DY via LU7DID-2  <SABM>

2: Fm: LU9DGN To: LU3DY via LU7DID-2* <SABM>

2: Fm: LU3DY To: LU9DGN via LU7DID-2 <UA>

2: Fm: LU3DY To: LU9DGN via LU7DID-2* <UA>


Please note that each listener has to have a different CallSign-SSID assigned in order to define uniquely which is the exit port of the frames.


Aliases are used mostly by routing functions, if not informed the default stated in the ROUTER section of the DIGIPLEX.INI file will be used. The alias is not informed merely by stating two “,” together.


Connection Security Configuration


Starting with AGWPE Version 2000.78 and up a special connection security verification has been introduced.


Basically, when applications connects to AGWPE using the WinSock API the connected application will be able to interact (successfully interchange frames between the application and and AGWPE) when the following conditions are met:


·        Accept only from MyComputer”.

Only applications physically running at the same machine than AGWPE will be authorized to connect.

·        Accept only from MyLAN (Standard Security)”.

Only applications running on machines at IP subnets to which the machine where AGWPE is being run is connected will be authorized.

·        Accept from Anywhere (No Security)

No security validation, applications from any IP address could connect.


If the application doesn’t fulfill the above conditions still could be connected with AGWPE if a successful “login” process is performed using one of the valid UserId/Passwords (as defined in the AGWPE “WinSock Interface Security” dialog.


When the application where Digiplex is being run fulfills the above criterias no need for additional configuration do exists.


However, if the conditions are not met the UserId/Password to be used has to be configured thru the LOGIN and PASWD configuration directives of the DIGIPLEX section (if not indicated “no security” is assumed).


The security validation (if enabled) would also have some implicancies on the configuration of L2 Worm routes, those are going to be discussed on the relevant section.


SMART Directive


When the “SMART” directive is added on a Listener configuration the “hop-to-hop ack” or intelligent digipeating is enabled on it.






Please note that the activation of the SMART mode on a given listener has to be explicit, otherwise the digipeater will operate  just relaying frames, still other modes could be operational (such as L2 Worm and NETROM).


Please, also note that even if the Routers had been disabled the Quality value still needs to be informed; if you don’t use any router (in particular, if you don’t use the NETROM router) put any numeric value there between 1 and 255 just to satisfy the parsing of the Interface line.


For further information on the functional aspects of the SMART mode see Smart Mode.

ROUTER Directive


When the “ROUTER” directive is added on a Listener configuration and the ENABLED directive on the ROUTER section is set as YES this port will operate an L3 Router (actual modes supported will depend on the configuration of the DIGIPLEX, DIGI and NETROM directives on the ROUTER section).








Digiplex saves periodically a snapshot of it’s routes (both Digiplex and NETROM) on the ROUTES.INI file.


The format of statements in the file are as follows:


SYS NETROM NODE ADD {port} {callsign-ssid} {alias} [LOCK}

SYS NETROM ROUTE ADD {destination} {alias} {port} {callsign-ssid} {quality}


The content of the ROUTES.INI file is read back by Digiplex upon startup if the LOADROUTE directive is set to YES on the ROUTER section or when the SYS LOAD command is executed.


The content of the file is refreshed every [ROUTER].MASTER milliseconds.



The DIGIPLEX  program is intended to work over the traffic passing thru the AGWPE and thus it has almost no provision to be used by the end user, upon execution it will create a small icon on the Windows Tray Area.

The program will operate until it’s terminated by means of right clicking on the tray area icon with the mouse and selecting shutdown.

The program requires the AGWPE program to be up and running in order to operate because it relies on it to receive and transmit AX.25 frames, if the communication with the AGWPE program is interrupted during the course of the operation a retry mode will be entered in order to regain that communication if the RECOVER parameter on the DIGIPLEX section is set to YES, and will be terminated if set to NOT (default and recommended setting).


Distributing Resources


Historically, amateur radio applications has been run on a single computer, from simple terminal programs to DOS based relatively complex packages such as the G8BPQ Node software or the F6FBB BBS package; some limited implementation of phone, serial or ethernet connections to access the applications were developed over time, but in most cases that was just a different way to access the application  as alternatives to the regular AX.25 packet network (i.e. for maintenance purposes, or for faster speed). This is adequate for most occasional uses, such as checking the mail on the home BBS or doing a file transfer, but has been a growing headache to operators trying to cope with high volume or network critical nodes where high availability is required such as NETROM nodes or BBS.


The combination of the application program (i.e. DIGIPLEX) with the AX.25 Manager (AGWPE) still could  run on the same machine, but for the first time it not necessarily has to.


Users could run all the programs under a single Windows 95/98/NT operating system on the simplest configuration, however as long as there is a permanent TCP/IP connection of adequate speed nothing prevents the application program and the L2 Manager (AGWPE) to be on different machines, when implementing a distributed configuration.


I do estimate that over the time and thru experimentation hams will implement very sophisticated and complex network topologies based on that facility, some of them that could be truly not imaginable now. However some of the likely scenarios would be:



The application program DIGIPLEX and  AGWPE operates in the same machine who also manages the physical AX.25 assets such as TNCs, soundcards or Baycom modems.



One machine in a LAN hosts AGWPE and the physical AX.25 assets such as TNCs, soundcards or Baycom modems while on another machine the application software DIGIPLEX  is run. Both machines has to have TCP/IP connectivity and be properly configured for that, usually a network cabling of some sort has to be implemented (such as a coax or UTP cabling). This could be a good solution for both ocassional users that wish to keep the “hardware” stuff confined to a machine (possibly at some remote location of the home) while still be able to use the packet applications from the most often used machines as well as operators of full fledged nodes that wish to spread the load among different machines. Several DIGIPLEX programs could be run at the same time connected with a single AGWPE instance provided that all of them register different callsigns, this might be a possible solution when different combination of cross-port operations are desired.


A great deal of practical experimentation and real world needs will dictated which is the most likely scenario for the use of this program, but after all that is what amateur radio is all about, experimentation.


The program uses the distributed nature of the AGWPE API to implement the L2 Worm mode.




“Normal” Mode


This mode is the most classic behaviour of a digipeater, frames heard in one port are retransmitted thru the same or different  port, no state is remembered by the digipeater nor any optimization is attempted.

It will work better when both ports being digipeated operates at the same speed over relatively uncrowded frequencies.


Could be used, of course, as a “classic” L2 digipeater relaying frames on the same port in order to leverage on the coverage of a given station.


This behaviour is set at the listener level, the “NORMAL” mode will be the default one when no options are indicated.



APRS Compatibility Mode


Several features were added to partially support the operation on APRS.


In order to activate the extra features related to APRS the listener requires an additional parameter (“,APRS”); a listener entry not supporting APRS will be like:





While a listener entry supporting APRS





The behaviour of a listener to which the “APRS” configuration token had been added will be controlled by the parameters on the [APRS] and [APRS_ALIAS] sections at the DIGIPLEX.INI file.


The entries at the [APRS] Section that could be used are:


This is a list of comma separated destinations that will be managed as APRS destinations (i.e. WIDE or NARROW).

The behaviour will be that when a frame is detected requiring to be digipeated by any of the callsign+SSID the following action is performed:


This entry will control whether or not alias substitution is allowed (YES) or not (NOT, default).

When activated the entries at the [APRS_ALIAS] section is used to identify whether actual substitutions are required.


This entry controls whether destinations in the form “WIDEn-m” are supported (YES) or not (NOT,default).

When supported if a frame pointed to be digied by “WIDEn-m” is detected, “m” is decreased till it reach 0 and the frame is resent; when it reach zero the frame is no longer resend. The previous WIDEn-m is replaced by the callsign-ssid of the listener where the frame was heard, the frame is sent thru all APRS enabled listeners.


Similar to WIDEn-m


This entry controls whether APRS frames are enforced to be UNPROTO (UI frames) or any frame type will be supported. It’s worth to note this setting only affects frames where APRS like digipeater names are used (i.e. WIDE, in general those defined at the ALIAS entry) and NOT any regular frame using the digipeater.


The entries at the [APRS_ALIAS] are a list of substitutions in the form:


{ALIAS}={ALIAS To be substituted by}




Layer 3 NET/ROM Router


The digiplex program implements two routing algorithms; the routing capability is in general enabled with the ENABLED clause on the ROUTER section of the DIGIPLEX.INI file, on top of that each router has to be specifically enabled.


If [ROUTER].ENABLED=NOT the SMART mode still could be used but the node won’t attempt to neither collect nor route frames in any way; in this situation the program could be seen as a simple “one-hop” router that still could be used as a cross-port digipeater.


When ENABLED=YES the program will behave depending on the configuration as:



The modes will be seen with more detail on the incoming sections.


NET/ROM Router


The DIGIPLEX program will announce itself to the network as a NET/ROM compliant node thru all interfaces where the clause “ROUTER” is indicated.


The implementation will:



The implementation aims to achieve some NET/ROM interoperability in order to interact with neighboor NET/ROM nodes and to get some routing benefits for the digipeater (such as to tunnel thru a NET/ROM cloud on the SMART digipeating mode) but it’s not aimed to provide a full implementation of NET/ROM nor to become a NET/ROM router as it’s core functionality. Full compatibility with all NET/ROM implementations is yet to be tested; all tests done so far were done with G8BPQ and (X)Net neighboor nodes.


The NETROM=YES clause on the ROUTER section enables the NETROM router.


NET/ROM Router Configuration


Actual configuration of the NETROM router should follow the local LAN conventions and recommendations, please check with your neighboor sysops for guidance.


A tipical configuration follows






















This configuration would keep the internal cycle of Digiplex at once per minute  (MASTER). Routes would be saved on the ROUTES.INI file at

each cycle and loaded inmediately after restart (LOADROUTE=YES).


The NODES frame would be sent every 60 master cycles (L3POLL).


Inmediately after hearing a station a nominal Obsolesence value of 60

would be assigned and reduced at every master cycle until the minumum

(L3OBSMIN) is reached; when that happens the route will be removed.


Layer 4 Connections will last a maximum of 240 Secs (L4TIMEOUT) in idle

state and frames would be sent 2 at a time (L4WINDOW).


The minimum quality to export a given route would be L3QUALMIN and

whenever necessary a default quality of L3QUALDEF will be used.


NET/ROM Managed Applications


Digiplex allows to define applications to be broadcasted as NET/ROM nodes so other neighboor nodes could access them using a Layer 3 routing; typically such applications are BBS, DX-Cluster, Gateways, Conference Servers or other common infrastructure services.


The application is assumed to:


·        Be executed on the same node than the Digiplex node that publish them.

·        Be accessible thru the loopback port.


In order to define such applications the NETROM.APPLICATION section of the DIGIPLEX.INI file must be configured.


Each application will be configured with an entry using the following format:




The NickName is a fantasy name that has no purpose at this point other than to differentiate entries on the configuration file.


The CallSign-SSID is the one to be used to connect the application (it must be the same to be used if the application were connected using a regular AX.25 connection).


The ALIAS will define the alternate NET/ROM name to be used for broadcast purposes.


The maximum number of managed applications to be defined is 16.


Managed applications are a concept to be applied only with the program operating as a NET/ROM node.


You could manage the network horizon of managed applications thru the selection of the quality assigned to each port (thru the Listener definition) and the minimum quality to export (L3QUALMIN).


NETROM Nodes Block


In certain network scenarios a node could be heard but not contacted to establish a link (either under INP3 or normal NETROM).


In such scenario attempts to connect will be performed from time to time and even if the route wouldn’t be established as good the continuous attempt to establish a doomed link might create unnecesary interferences and channel load.


When such situation exists nodes that will be blocked for any attempt of direct contact might be defined including them on the [NETROM.BLOCK] section of the DIGIPLEX.INI file as follows:






As many entries as needed could be informed.


Basically, the entries forces Digiplex not to take any broadcast from the indicated nodes as well as do not include them on any Digiplex routes broadcast; nodes listed would be prevented to be considered as direct neighboors but they could still be accessed if reported by a non-blocked neighboor on it’s own routes.


INP3 Compatibility


Digiplex does not implements INP3 as a routing algorithm, however it address compatibility issues thru the following functions:




NETROM Improvements


Even if Digiplex isn’t a NETROM/INP3 compliant router it does implements some concepts from INP3 to improve the overall performance and routing capabilities.


It does so in a way that remains compatible with both “old NETROM” (i.e. BPQ) or new INP3 routers (i.e. XNet).


The enhancements are:



This behaviour could be turned off with the directive [NETROM].INP3=NOT, in that case Digiplex will route strictly based on the best quality to a given destination based on the combination of the Quality of each port (as assigned by the sysop on the [INTERFACE] section) and the Quality reported by each neighboor to a given destination.


Digiplex Internode Protocol


The Digiplex origin of frames is marked thru a RIF formatted fields using the $Z marker (pretty much in the same way than INP3 routers marks themselves using the $N marker) so Digiplex routers could be made aware of which of it’s neighboors are also Digiplex.


When that situation is detected and the [NETROM].COMPRESS configuration directive is set to YES the exchange of frames is made using compression (LZRW1/KH algorithm) in order to save bandwidth. Compressed frames are carried using the PID 0xCA in order not to conflict with other non-Digiplex NETROM routers in the area.


The NETROM protocol is fully used, only that the Layer 2 info section of the frame is compressed (if compression makes sense for a particular frame).


Frames where compression doesn’t yield any benefit are transmitted using the regular NETROM PID 0xCF; both kind of frames could then appear on any given connection on any order depending on the actual data being carried.


Compression usually achieves an average of 20-30% reduction of the gross volume transferred creating bandwidth savings.



NETROM Tunneling (SMART Mode)


If the NETROM router is enabled the information gathered by the node (as a NETROM router) will be under certain circumstances used to optimize connections which aren’t NETROM (ie. regular AX.25 connections).


If a frame which has one of the CALLSIGN-SSID of the node interfaces as part of the path is heard and then the SMART hop-2-hop mechanism is activated (if enabled) the destination is inspected to see if it’s a known NETROM resource.


If it is; instead of trying to connect it directly the NETROM node that should be used to route NETROM frames for it is connected instead (based on the best quality path); once that connection (which is performed like a end user) is established then a “C Destination”

is transmitted to the NETROM node in order to trigger the transport of the frame thru the NETROM network tunneling thru it.





When all routing attempts fails using NETROM  another router might step into action if enabled with the MHEARD=YES directive in the ROUTER section.


It’s a simple guess-routing appropriate for one hop connections where the destination is contacted directly (using a simple L2 connection, it doesn’t require to be a node itself) thru the last port it was heard.


Chances are that the station was upon a time heard and kept by AGWPE on the Mheard list but no longer available; obviously this routing will succeed if the station is available and the node is able to establish a connection with it.


The MHEARD router works at two different moments:



HTTPd Server


Digiplex includes a simple Web Server that could be used to gather status information about the node thru simple commands, this Web Server (HTTPd server) is completely optional and it’s not involved on any actual operation of the node.


Installation of the Web Interface


·        Configure the HTTP section of DIGIPLEX.INI




  QTH=QTH Information

  SYSOP=Sysop Name and/or CallSign


Change the PORT value to any suitable value for your installation, if you  have already a Web Server running probably port 80 is already hooked up  by it. Try Port 8009. Beware NOT to use any port currently in use,  specially the ports allocated by AGWPE (8000,...). Use the netstat –a  command in case of doubt.


You could customize all command related pages changing   the TEMPLATE.HTM file to fit the overall “look & feel” of the Web site where the pages would be presented.


Content Management


The server isn’t intended to provide content by itself but just to be integrated with another (existing) Web Server and to  provide the content related to the node operation.


The logic of the server to provide content will be:


·        If the required resource has an extension different from “HTM” it will be served as a binary file.

o       A.HTM AX.25 Parameters.

·        All the internally produced pages will use the file TEMPLATE.HTM as the mask to produce the content. The meta-tag “<#DATA>” will receive the specific content of the command being executed internally.

·        The metatags <#QTH>, <#SYSOP> and <#ALIAS> will be replaced by the respective configuration parameters.



The HTTPd server does not execute third party programs (CGI or others) other than the supplied set for security reasons.

Smart Mode


The “Smart” mode is an special hop-to-hop acknowledge mechanism, still at a very early stage, intended to increase the efficiency of the digi operation thru the leverage of the existing AGW Packet Engine AX.25 processing.


It name cames after all the trickery involved on the management of the frames as opposed to just flip a bit on the frame VIA area and blindly retransmit it.


It’s activated when the token “SMART” is added to a listener at the [LISTENER] section.


Functional Description


When a frame is detected pointing to one of the valid listeners of the digipeater the following process occurs:



Warning – In order for this mode to operate a LoopBack port has to be defined on AGWPE


Command Line Interface (CLI)


The program allows connections to be made over radio to it and it provides a (rather rudimentary) interface to the user.


Current commands not necessarily will survive to the late stages of development, it could be protected or even could be removed as development progress.


To access the CLI you might connect to the Callsign-SSID stated on the CALLSIGN configuration parameter (DIGIPLEX section) thru any of the ports for which a listener had been configured.


Upon connection the program will basically wait for the first user input, this might be rather confusing, but it’s necessary to understand whether it’s a “normal” user or another node willing to start an internode connection.


Upon the first command (or even the first CR) sent a banner will be displayed, this is that way to ensure the proper PID of the connection (user or internode) is sensed before the first frame is sent.


Then the list of available functions could be obtained with the “?” or “h” commands.


The (probably) most useful commands will be:



No command issued could create any real harm (except, perhaps, the SYS command), but of course, an improper sequence of commands might lead to the improper function of the node, beside the above commands all others should be exercised with caution and an overall experimental mood.


Most of the commands results would be self explanatory with the probably exception of the “n *” command; the format and meaning of the result will be:


P(n)XN(ALIAS:CALLSIGN) St(XXX) RTT(nnn) Q(mmm) [DPX|LOCAL|LOCK|IN3] D(hh:mm:ss)

     N(ALIAS:CALLSIGN) O(nn) Q(nnn)


The first line reflect a neighboor node heard thru “P” port, with a Status (St) that could be

·        CONN Connected

·        DISC Disconnected

·        TRY! Connection being attempted

·        CUT! Disconnection in progress


The “X” value could be

·        > This is the present preferred route to this destination.

·        ? This destination seems to have no valid routes.

·        Blank This is not the preferred route for this destination.


When connected the RTT meassure the turnaround time in milliseconds, Q the quality applied to this particular neighboor, special conditions of that neighboor such as:

·        LOCK Locked Route

·        LOC Local Application

·        IN3 NETROM/INP3 Neighboor

·        DPX Digiplex Neighboor


And finally the timestamp of the last broadcast heard from that neighboor.


The second line format refers to routes thru the neighboor. Q reflects the compound quality to that node (Quality to neighboor factored to Quality between the neighboor and that destination) and O reflects the Obsolecense counter for that particular entry.


Destinations thru nodes currently not connected aren’t shown, if any, will be presented again when the neighboor node could be contacted.





The configuration of the Command Line Interface is made thru the entries at the CLI section of the DIGIPLEX.INI file or thru the Properties GUI


Relevant entries are:


·        ACTIVE (default YES), enables the Command Line Interface; the CLI could only be disabled if the program is used as a Cross-Port digipeater..

·         TIMEOUT (default 60000, 1 Min), this is the amount of inactive time a connection could have before to be terminated automatically.

·        WELCOME, Welcome String to be sent to the user upon connection (both AX.25 and Telnet).

·        ERRORMAX (default 3), is the maximum number of consecutive command errors a session will be tolerated to have before been disconnected.


Once enabled the Telnet Client will export the CALLSIGN:ALIAS as a managed application for other neighboor NETROM nodes to establish routes to it.


CLI Security


All commands accessible thru the CLI have a “security level” associated with it; security levels could range from 00 (minimum) to 255 (Maximum).


Each user connected to the node is associated with a “security level” too, so that particular user could execute commands whose security level is lower or equal than his/her own security level.


AX.25 user have a security level of $08 and Web users have a default security level of $00; this is not configurable.


All informational commands have a security level of $00 associated. All node commands have a security level of $FF.


In order to achieve the security level required to execute the SYS command ($FF) a LOGIN command must be issued.


The node will react with a 5 number (random) sequence which will reflect positions on the node password ([DIGIPLEX].NODEPASS); the characters on that positions must be supplied in order for the node to enter a “sysop authorization” mode where the SYS command is enabled; the password validation is case sensitive.


If not configured the default NODEPASS value is “DIGIPLEX”.


Splash File (Welcome.INF)


When a connection is made (AX.25) the file WELCOME.INF will be sent to the user if exists as a banner (or splash file); the content of the file could be customized by the operator of the node to provide short messages and suitable operational information.


If specialised messages are required for each port files named as Cx.INF could be configured (being x=port); if a file with this naming convention is found it will be sent instead of the WELCOME.INF file.


If the file is not found a default banner is sent to the user as set on the [CLI].WELCOME configuration entry of DIGIPLEX.INI


Other Text Files (*.INF)


The following files could be configured by the sysop and shown to the users instead of the default messages.


MOTD.INF     Message of the Day, sent inmediately after the WELCOME.INF file if present.

Mx.INF                With x=port will be sent instead of MOTD.INF if present when a connection is made on      that port.

HELP.INF       Help file to be shown then the ? or h command is executed at the CLI.



Command Reference


Follows the reference of the commands available at the node.


A Command


This command list the AX.25 parameters of a given interface as configured in AGWPE, general format is:


          A {interface}




AX.25 Parameters for Port

Parameters for Port (nnn) Port n with XXXXXXXXX

OnAirBaud      (xxx)

Traffic Level  (xxx)

TXDelay        (xxx)

TxTail         (xxx)

Persist        (xxx)

SlotTime       (xxx)

MaxFrame       (xxx)

AX25Channel    (xxx)

HowManyBytes   (xxx)


Please refer to the AGWPE documentation for the meaning of each configuration parameter.


Layer 2 configuration paremeters could not be changed from Digiplex, appropriate changes must be done using AGWPE facilities.


P Command


This command list the configured ports as defined in AGWPE, general format is:







Int(xxx) Type(AX.25) Port(n) XXXXX—(Description)--


            Int        Is the interface nickname as configured in the [INTERFACE] section.

            Type    AX.25

            Port      Port number as defined in AGWPE



Layer 2 configuration paremeters could not be changed from Digiplex, appropriate changes must be done using AGWPE facilities.


J Command


This command list the stations heard on a given interface as reported by AGWPE, general format is:


          J {interface}   or

                            MH {interface)




Heard List for Interface(xxx)

Stations Heard on Port (xxx) XXXXXXXXXXXXXXXX

     AAAAA Mar,03Abr2001  11:37:26 Mar,03Abr2001 13:12:37


All heard stations in the port are listed with the indication of the first time and the last time the station was heard.


This report is produced with information as provided by AGWPE, including the order or the entries.


N Command


The command list all Nodes known to the NETROM router, the argument will define the format of the list:


N with no arguments.


A simple list with a summary of all nodes known to the router will be produced

such as:





N1OTX:BROCK             TNCLI:TELMGR            G0CGL:DXCCGL

LU3DY:RCBURZ            LU3DY-4:3DYNOD          LU6DK:BBS6DK

LW4DBE:DBEBBS           LU3ERX-4:LANUS          LU6DK-4:RCLDZ

LU9DGN-1:TMPY           LW4DBE-4:DBENOD         LU4DQ-4:R.C.Q

LW1DTJ-4:SUR            LU4DO:DO                LU4DO-4:AVELLA



Nodes list will be produced ordered alphabetically by Alias name.                                                       

N *


A comprehensive list of all neighboor nodes and routes will be produced, such as


NETROM Routes:

P(4)>N(LUGATE:LU7DID) St(-*-)  Q(255)  LOC D(11:37:16 a.m.)

P(4)>N(ABROWN:LU7DID-4) St(CONN)  Q(71)  IN3 D(01:48:18 p.m.)

    >N(WOOLDX:GB7CGL) O(52) Q(67)

    >N(PISAGW:IW0DAM) O(52) Q(67)

    >N(NQNGW:LU0YYN) O(52) Q(67)

     N(LUGATE:LU7DID) O(52) Q(67)

    >N(DXCDID:LU7DID-3) O(52) Q(67)

    >N(BROCK:N1OTX) O(52) Q(67)

    >N(TELMGR:TNCLI) O(52) Q(67)

    >N(DXCCGL:G0CGL) O(52) Q(67)

     N(RCBURZ:LU3DY) O(51) Q(64)

     N(3DYNOD:LU3DY-4) O(51) Q(66)                                             

     N(BBS6DK:LU6DK) O(51) Q(17)

     N(DBEBBS:LW4DBE) O(51) Q(17)

     N(LANUS:LU3ERX-4) O(50) Q(43)

     N(RCLDZ:LU6DK-4) O(50) Q(48)

     N(TMPY:LU9DGN-1) O(60) Q(43)

     N(DBENOD:LW4DBE-4) O(50) Q(48)

P(1)>N(RCLDZ:LU6DK-4) St(DISC)  Q(215) D(01:40:48 p.m.)

    >N(BBS6DK:LU6DK) O(53) Q(83)

     N(DBENOD:LW4DBE-4) O(53) Q(7)

     N(3DYNOD:LU3DY-4) O(53) Q(7)

     N(RCBURZ:LU3DY) O(53) Q(7)

     N(LANUS:LU3ERX-4) O(53) Q(5)

     N(TMPY:LU9DGN-1) O(53) Q(5)

P(1)>N(DBENOD:LW4DBE-4) St(DISC)  Q(215) D(01:34:52 p.m.)

    >N(DBEBBS:LW4DBE) O(47) Q(83)

     N(RCLDZ:LU6DK-4) O(32) Q(8)

    >N(R.C.Q:LU4DQ-4) O(47) Q(8)

    >N(SUR:LW1DTJ-4) O(47) Q(8)

     N(3DYNOD:LU3DY-4) O(47) Q(8)

     N(RCBURZ:LU3DY) O(47) Q(8)

P(2)>N(LANUS:LU3ERX-4) St(DISC)  Q(229) D(01:40:51 p.m.)

    >N(DO:LU4DO) O(22) Q(182)

    >N(AVELLA:LU4DO-4) O(22) Q(186)

    >N(MIKE:LU9DGN) O(22) Q(210)

    >N(TMPY:LU9DGN-1) O(22) Q(210)

P(1)>N(3DYNOD:LU3DY-4) St(DISC)  Q(215) D(01:28:57 p.m.)

    >N(RCBURZ:LU3DY) O(41) Q(209)

     N(BBS6DK:LU6DK) O(41) Q(62)

     N(RCLDZ:LU6DK-4) O(41) Q(161)

     N(DBENOD:LW4DBE-4) O(41) Q(161)

     N(DBEBBS:LW4DBE) O(41) Q(62)      


Lines starting with a “P” (port) refers to neighboor nodes directly heard, the Alias, Callsign-SSID, current status, Quality and last time heard is listed.


Also the qualifiers LOC, IN3, DPX and LOCK might appear showing that neighboor is a Local (managed application), INP3, Digiplex or a Locked route.


If the INP3 compatibility mode is enabled the current RTT to that neighboor is shown, the Obsolesence is listed otherwise).


Dependent nodes (nodes routed thru a neighboor) are listed following the neighboor entry.


For each route the current obsolesence and the compound quality of the route is shown.


Entries listed with a “>” means currently selected as best route, “?” means invalid as a route.




This command will have a content similar to N * but only listing entries related to the neighboor “Callsign-SSID”.

R Command

The Route command list the possible routes for a given destination, it list both the “would be result” of the NETROM and MHEARD routers.


            R CALLSIGN-SSID or R ALIAS


will produce as a result


NETROM Route: Call(CALLSIGN-SSID) à (Port:Node)



NO ROUTE will be shown instead of a route if none could be found.

This command has no effect on the actual routes, it’s merely for information purposes, to set or remove routes the SYS command must be used.

L Command


Display the on-going L2/L3/L4 links active at the node:


L3 NETROM Connections:

Node(4:LU7DID-4)  St(CONN)

Node(1:LU6DK-4)  St(DISC)

Node(1:LW4DBE-4)  St(DISC)

Node(2:LU3ERX-4)  St(DISC)

Node(1:LU3DY-4)  St(DISC)



L2 Digipeater Connections:

Id(8) St(CONN) (2:LU9DGN)--[D00008-15:LU9DGN-14]                                 


L2 Digipeater Connections refers to virtual circuits held by the cross-digipeater function when the smart mode is active. The originator of the circuit, the internal callsign-ssid used and the final destination are listed.


U Command


Display the on-going L2/L3/L4 links active at the node:


L2 Connections:

Port(4) LU7DID<->LU7DID-1 Auth(8) St(0)

Port(4) LU7DID-4<->LU7DID-1 Auth(8) St(0)

Port(4) LU7DID-13<->LU7DID-1 Auth(8) St(0)

Port(4) LU7DID-12<->LU7DID-1 Auth(8) St(0)

Port(4) LU7DID-5<->LU7DID-1 Auth(8) St(0)


L2 Digipeater Connections:

Id(9) St(4) (2:LU9DGN)--[D00009-15:LU9DGN-15]--(1:LU6DK)

Id(10) St(0) (2:LU9DGN)--[D00010-15:LU9DGN-14]--(1:LU3DY)


NETROM L4 Connections:

(LU7DID-4<->LU7DID-1) Loc(1:9) Rem(8:37) Window(2) St(2)



L2 Digipeater Connections refers to virtual circuits held by the cross-digipeater function when the smart mode is active. The originator of the circuit, the internal callsign-ssid used and the final destination are listed.


C Command


The connect command could be used by stations logged on the node and will produce different results based on the destination and the current configuration of the node.


The general format is:


     C {port} CALLSIGN-SSID {via Call1 Call2)


If the port is omitted the destination (CALLSIGN-SSID) will be handled as a NETROM node and the proper route to it will be defined based on routing information, if a valid route could be found a L3/L4 connection will be started.


If no NETROM route could be found a best can do routing attempt will be made by the MHEARD router if enabled; the MHEARD router could only route if the station was heard thru a single port, if a given target station was heard thru more than one port the MHEARD router will not try to route the connect. Connections started by the MHEARD router are Layer 2 AX.25 connections even if the destination is a NETROM node.


Other (generic) destinations could be connected but the port information must be provided. Digiplex doesn’t alter the port information when provided, also Layer 2 AX.25 connections are attempted when the port information is provided disregarding the actual nature of the target (node or not node).


When port information is provided the node behaves as a gateway.


V Command


This command display the current software level of the node

Version 0.72 Build(22)

DATE Command


This command a timestamp of the current clock of the node for verification purposes


Date/Time: 03/04/01 01:20:36 p.m.

I Command


The command list an informational picture of the status of the node when executed without arguments:


DigiPlex Version 0.72 Build(22) Pedro E. Colla (LU7DID) 2000,2001

Digipeater Node(LU7DID-1)

Up since: 03/04/01 11:37:15 a.m.

L2 Connections

Port(4) Call(LU7DID)

Port(4) Call(LU7DID-4)

Port(4) Call(LU7DID-15)

Defined Interface(s)

Name(AX1) Type(AX.25) Port(1) Call(LU7DID-1)

   APRS(YES) Smart(YES) Router(YES

Name(AX2) Type(AX.25) Port(2) Call(LU7DID-7)

   APRS(YES) Smart(YES) Router(YES

Name(AX3) Type(AX.25) Port(3) Call(LU7DID-8)

   APRS(YES) Smart(YES) Router(YES

Name(LPB) Type(AX.25) Port(4) Call(LU7DID-9)

   APRS(YES) Smart(YES) Router(YES


L2 Connections 3

L2 Digipeater Connections 0

MHeard Router: TRUE


 Alias:   DBROWN

 Clock:   60000 mSecs

 Nodes:   22


 Router Parameters

   -- L3 --

   Obs (Ini):60

   Obs (Min):1




   Broadcast:60 Mins

   Compress :TRUE

   Publish  :TRUE

   RTT (Ini):60000 mSecs

   RTT (Max):600000 mSecs

   Query RTT:1200000 mSecs

   -- L4 --

   L4 Window:2

   L4 TOut  :240000 mSecs          




When the command I (Information) is executed with arguments a file could be defined by the operator to be sent instead of the default content of the command.


Information associated must be configured on a file named as {Arg}.INF.




If the user types




The content of the file HARDWARE.INF will be sent if the file exists.


SYS Command


All node management commands have been grouped into the SYS command; this command will operate with sub-arguments as follows:


          SYS NETROM ?

         SYS NETROM SET ParmName {Value}

                        * ParmName is the same name of parameter

                          in DIGIPLEX.INI

         SYS NETROM BROADCAST (Forces a NETROM Broadcast)


         SYS NETROM NODE {ADD|DEL} {port} {callsign} {alias} LOCK|LOCAL

         SYS NETROM ROUTE ADD|DEL {dest} {alias} {port}{callsign} {Qty}


         SYS INTERFACE {Interface} QUALITY nnn  1..255

         SYS INTERFACE {Interface} APRS {ON|OFF}

         SYS INTERFACE {Interface} ROUTER {ON|OFF}

         SYS INTERFACE {Interface} TCP {ON|OFF}

         SYS INTERFACE {Interface} SMART {ON|OFF}


         SYS BEACON ?

         SYS BEACON EVERY {value}

         SYS BEACON TEXT {beacon_text}

         SYS BEACON ID {beacon_id}



         SYS MHEARD ?

         SYS MHEARD {ON|OFF}  {Only allowed if previosly defined}


         SYS SMART ?

         SYS SMART RESET Pid


         SYS KERNEL TRACE {n}


         SYS SHUTDOWN     (Requires auth level of 255 to execute)


The SYS command requires an authorization level of $FF to be executed, regular AX.25 connections carries an authorization level of $08.


In order for the SYS command to be authorized the LOGIN command must be used first.


LOGIN Command


Upon execution the user is challenged with 5 random position of a passphrase such as


System Key à[ 3 4 1 2 1 ]


The correct letters (case sensitive) must be provided for those positions in order for the access to be cleared.


If the access is validated an “Ok” is produced and the prompt presented, if the access is not validated only the prompt will be presented.


The password or passphrase itself is configured on [DIGIPLEX].NODEPASS and if not configured is set as “DIGIPLEX” by default.


Command Line Interface Aliases


Aliases could be established for commonly used commands thru the CLI.ALIAS section of the DIGIPLEX.INI file or equivalent GUI facility.


The entries will follow the following sintax:


ALIAS=Command to be Executed,Description


All Aliased commands have a security setting of $00 (enabled to all users).


FlexNet Compatibility


A couple of paragraphs related to FlexNet compatibility.


Up to level 0.70 some attempt to provide FlexNet interoperability had been done; given the absolute mistery on the FlexNet internode protocol and the availability of FlexNet compatible node software for the AGW Packet Engine platform all FlexNet compatibility functions had been removed.


There is no current plan to support any FlexNet related function in the future other than the interoperability as a digipeater.





In case the program doesn’t work as expected several reasons might happen for that, the most common situations are:



In general, in case of difficulty it might be helpful to activate the logging of the program (DEBUG=YES) and slowly increase (on sucessive tries) the level of tracing (TRACE={1à5).


Can not establish communication with AGWPE


In case communication with AGWPE could not be established the following configuration should be checked:


·        Ensure AGWPE is up and running.



Does not operates correctly as a digipeater


Under proper operation conditions the program operation should be easily seen thru the monitoring of the AX.25 channels over which it operates; a frame addressed in one port via the callsign-ssid of the digipeater should be seen shortly thereafter as being repeated on the output port and viceversa. This could be monitored with either AGWTerm or AGWMonitor or any other suitable packet terminal program.


If this behaviour could not be obtained check the following topics:


·        Ensure the CALLSIGN entry in the DIGIPLEX.INI file is informed and correct.

·        Ensure the callsign+ssid used on the CALLSIGN is not being used by any other program concurrently on the same AGWPE (see About/WinSocks).

·        Ensure both Port IN and Port OUT entries of the listeners are informed, whenever not informed they default to zero (0) thus making the digipeater useless.


A Defined Listener doesn’t seems to work


A defined listener might be in conflict with another listener (same callsign-ssid over either the same input or output port) or an invalid entry (improper format or an invalid port number).

Review the DIGIPLEX.INI entries at the LISTENER section looking for obvious problems and typos, the format should be







If still having problems turn the DEBUG mode ON (DEBUG=YES with TRACE=1) and look at the generated DIGIPLEX.LOG file during initialization to see if any error message do appear.


Digiplex and the AR DX Cluster


When the AR DX Cluster is defined as a “NETROM Managed Application” users could not get into the cluster thru NETROM routes.


This is because AR DX Cluster has a bug with SSID=15, the author doesn’t answer mails related to the problem.


A workaround is to define DXCLUSTER=YES on the DIGIPLEX section of DIGIPLEX.INI, this will force Digiplex to restrict the usage of SSIDs into the range 0 to 14.

Throughput of the digipeating process is slow


As stated during the functional discussion (see Usage) an AX.25 Layer 2 repeater is a relatively dumb device which blindly relays information as it comes thru the channel.


To digipeat frames over the same channel is usually regarded as a very inefficient process because, essentially, the bandwidth is used twice or more (the original frame and each “digipeated” version); it’s usage is then recommended when direct visibility between stations is impossible to achieve.


At the same time, since the sender station is not aware of the status of the “digipeated” frames (even if it hears the digipeater station) depending on the AX.25 settings being used additional supervisory frames will start to be sent.


In general, since the digipeating process doesn’t provides a transport mechanism per se (collided frames are lost), the performance of the digipeater will be mediocre on busy channels (in cases, will make the busy channels busier).


Using the digipeater across ports isn’t as inefficient as stated before since the bandwidth on each channel is used only once, still additional overhead due to supervisory frames will occur depending on the AX.25 settings on both ends; in order to improve the throughput the following actions might be attempted.


·        Try to use the digipeater across channels of the same or similar speed, digipeating across ports with different speed will work but the faster end will have a trend to generate supervisory frames while the slower end is still trying to transport the frame.

·        The AX.25 TNC settings should be “hotter” on the slowest port (specially PERSIST).

·        Keep the MAXFRAME smaller on the slower port.


The GUI dialog appears right on Start, Nothing seems to Work.


Check if the file L2XDIGI.ICO is at the Digiplex directory, if not download it from the lattest package or directly from http://www.qsl.net/lu7did/bin/digiplex/l2xdigi_ico.zip


If not run DIGIPLEX with DEBUG=YES, TRACE=1 and inspect on the DIGIPLEX.LOG for problems during the initialization (watch for the word “Exception”).


Failure to interact with a NETROM node delivering CTEXT.


AGW Packet Engine Version 2001.10+ must be used.


If already using it run DIGIPLEX with DEBUG=YES, TRACE=1 and inspect on the DIGIPLEX.LOG for problems during the initialization.


Discussion of the Program Modes.


Currently, the Digiplex program implements several concepts in one; some of them are closely related while others are relatively independent. Unfortunately the user interface is still very primitive and relatively hard for the user to configure the different modes.


Those concepts are the SMART mode, the NETROM routing and the MHEARD routing.


It is worth to clarify the role of each one.



The SMART mode is enabled at the Listener level by means of the “SMART” directive, it deals only with the operation of the digipeater as “dumb” or “smart”; in other words, it controls whether or not a straight frame digipeating (dumb) or a “hop to hop ack” is performed. This mode could be used independent of all the others, even if no router at all is enabled this mode could be operated.





The NETROM mode is enabled by three configuration actions. Each listener has to be enabled for routing thru the usage of the ROUTER directive, the ENABLED configuration has to be set to YES and the NETROM configuration has to be set to YES also. When those conditions are met that particular listener will be sensitive to broadcasted NETROM routes (UI frames directed to NODES), will route NETROM L3 frames and could sustain connections from other nodes either to the listener itself (to access the Command Line Interface) or to any managed application. It will also broadcast it’s own routes periodically thru an UI frame directed to NODES. This mode could co-exist with the same listener operating as a DIGIPLEX node (albeit it’s not recommended at this stage of development). This mode is optional too, if you don’t want (need) a NETROM node, you could just not configure it.



The MHEARD mode is enabled by three configuration actions. Each listener has to be enabled for routing thru the usage of the ROUTER directive (same as NETROM), the ENABLED configuration has to be set to YES (same as NETROM).


When a listener on a node is enabled for the MHEARD mode connections attempts from a “connected” user with no port information will be attempted to be resolved looking for the destination on the AGWPE heard list.


If the destination could be found (univocally) in one port (not counting the loopback port) the connection will be triggered using that port; if not found or found on more than one port an error will be returned.




Suitability of a Wintel Box to operate as an Infrastructure resource.


Infrastructure resources are usually perceived as high reliability, boxed and single purpose devices that sits unattended on a mountain top or other isolated place; this is actually the case in most situations.


On that scenario the “perceived” stability of an Intel box running some variant of Windows as required by AGWPE doesn’t seems to fit as a solution.


Probably a PC running anything might not be a good solution for a mountain top in any case, just out of energy considerations; a dedicated and relatively simple box could do a great job on that role.


Still, to run a Wintel box on an unattended place is not as far fetched as it might sound, specially if WinNT or Win2000 are used; those operating system had almost none of the classical “unstabilities” of their small version cousins of the Win9x/ME kind, and are actually quite robust if carefully installed and maintained. Actually, many mission critical IT applications with extremely high availability are executed on such platform.


But Digiplex had been designed more as a routing complex for a power station on a given zone than as a “range extender” resource.


It’s main features are the cross-port capabilities (capability to link LANs from a common station with mutual accesibility), and classical on-the-LAN routing functions (NETROM and MHEARD); probably this order of importance is a fair statement in itself.


As such, the resources needed to achieve the purpose of the program would probably not be found at isolated or unattended places but at the very heart of a power station on a given area.


In the short term, and while the program is under development it doesn’t have the stability needed for a non-supervised operation; but if the development continues enough for it to achieve some level of maturity that scenario won’t be completely unthinkable.




A word about IP Addresses


If your machine is not connected to a LAN and have assigned a permanent address it is likely that even if your TCP/IP stack is configured you don’t have a concrete IP ADDRESS to set this program. In that case you should use what is known as the “loopback” IP Address, which is a special IP Address that the TCP/IP stack in your machine uses to communicate with itself. This loopback IP ADDRESS is usually either or and you should not need to configure anything to use it, it is just there already defined for you. Be aware that if you configure the loopback IP address all the programs must run on the same machine, you can not go distributed (aka split the programs in several machines) without properly configure them as a LAN each one with their own addressable IP number.

You could tell if your TCP/IP stack knows about the loopback address by doing on a MS-DOS session the following command




If you get an answer such as:


Pinging with 32 bytes of data:


Reply from bytes=32 time<10ms TTL=128

Reply from bytes=32 time<10ms TTL=128

Reply from bytes=32 time<10ms TTL=128

Reply from bytes=32 time<10ms TTL=128


Ping statistics for

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 0ms, Maximum =  0ms, Average =  0ms


Your setup will probably work without problems, beware if you get an answer like the



Pinging with 32 bytes of data:


Destination specified is invalid.

Destination specified is invalid.

Destination specified is invalid.

Destination specified is invalid.


Ping statistics for

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Approximate round trip times in milli-seconds:

    Minimum = 0ms, Maximum =  0ms, Average =  0ms



In the unlikely event that you try to run this program on an environment that allocates dynamically the IP Addresses (i.e. using BOOTP or DHCP) be aware that your IP Address might change over time and you should reflect that on the configuration if trying to use the programs distributed on several machines, however, even on such scenario using the loopback IP Address and everything on the same machine should not create any problem. If you are not working as a part of a big LAN, say a business environment, you should not be worried about this scenario.

Please refer to the documentation of your operating system on how to properly configure the TCP/IP stack on your machine for further information.

Known Bugs & Pending


·        After a while with AGWPE not available the program traps.

·        Ocasionally during a “hop-to-hop ack” interchange frames are retained on an intermediate node; the whole connection stops and eventually times out; the condition is cleared when any end of the connection sends something (this is probably an AGWPE problem but work is still being done on the subject).



Many people contributed with this program on its different development stages, I could not account for all of those that thru conversations (real, air or E-Mail) contributed to create in my mind the original idea.


The development itself wouldn’t be possible at all without George Rossopoulos (SV2AGW) providing the AGW Packet Engine (AGWPE) in the first place, extending the capability to interact with it thru TCP/IP as opposed to the somewhat arcane DDEML original interface the program had and lately reacting very promptly to make modifications and enhancements to AGWPE during the development and test stages.


During the test of the program (an ongoing process) I disturbed the patience of almost every sysop of my local LAN routing thru the local nodes the most exotic digipeater connection paths anyone could think and quite a few of corrupted or otherwise misbehaved AX.25 frames till I got things reasonably right; in particular Juan E. Sanchez (LU9DGN) suffered the program in very unstable and buggy conditions on his own node to allow me to have a peer to work out many of the internals of the program.


Most of the detailed tests performed involving remote TCP/IP connections involved the very important contribution of Paul Anderson (N1OTX) which tirelessy implemented configuration change after configuration change to allow me to evaluate (and correct) many aspects of that mode.


The fix that makes possible the work of the AR DX Cluster together with Digiplex could not have been possible without Eric Carling (G0CGL) “nightmare” on the solution; Eric was instrumental on the extensive (also exhaustive and somewhat boring) testing required to make the NETROM router to properly work and interact with other implementations.


Useful suggestions related to the APRS functions made by Olivier (F5PYF) and NETROM issues pointed by Christian (F5IX) lead for a consolidation of both functions.


Many other people contributed with suggestions, test reports and comments to be listed here, I could not move this program forward without their involvement.


Please note that a L2 Digipeater program (AGWDigi.EXE) written by George Rossopoulos (SV2AGW) is available and supported by the author; whenever a L2 digipeater that operates over a single port is needed the usage of that program is recommended.


I look forward for other people to actually use the program and provide positive or critic feedback of it just drop me a note with any special requirement or problem you might have.


I’m particularly interested on receiving benchmark information about throughput of the program under different scenarios.

Version Information


Initial release. Basic functionality. Distributed for initial evaluation.

SMART mode introduced, performance optimizations on the digipeater. Additional parameters introduced. Beacon reformulated.

Modification in the DIGIPLEX.INI format, multiple digipeater listeners allowed.

Added extended Beacon information (VERBOSE).

Added controls to avoid conflicting Listeners at the DIGIPLEX.INI configuration.

Added possibility to route beacon frames thru a digipeater path (please note that the digipeater will not digipeat it’s own beacon frames).

Added support for APR.

Added support for the L2 Worm Digipeater Protocol (Digipeat over TCP/IP).

Changed the Smart algorithm.

Added support for the “Drunk” hop to hop ack mode.

Several performance improvements.

Countless bugs removed.


Renamed into Digiplex Version 0.5 Beta


Clean up of the program.

Performance optimizations.

Bug solutions on the SMART mode (garbage I frames if connection drop In one end).


Pseudo L3 Layer (Router implemented).


Pseudo L3 Layer improved.


L2 Worm mode rewritten to avoid a dedicated TCP/IP client and server to be used. The AGWPE at the other end is directly connected instead of an intermediate Client/Server socket to be used.


Initial working implementation of the NET/ROM node.

Managed Applications concept implemented.

Countless bugs removed.

Unknown number of bugs introduced.


Modifications to the initial working implementation of the NET/ROM node.

Countless bugs removed.

Unknown number of bugs introduced.

The routers (both DIGIPLEX and NET/ROM) has to be used strictly on experimental grounds.


Modifications to the initial working implementation of the NET/ROM node.


Major modifications on the NETROM implementation, specially the routing.

Option to make general or local broadcasts of routes.

Fixed ROUTE command on CLI.

Applications are shown on the command N of the CLI.

Initial GUI interface.

Initial Web interface.

Telnet Server added.

Splash screen upon start added.

Could be used as a gateway now (C command on CLI).

Optionally load routes on start, file format different from previous versions.

Exception on UpdateNODES fixed.

Exception on FindNR3Route fixed.

Enhanced AX.25 timeout.

The usual crop of minor bugs fixed, too many to document.

Who knows what other “feature” added in the process.



Enhancements on the connection logic.

Update of the GUI.

Fix of the compatibility issue with AR DX Cluster.        

Changes on the APRS WIDEN-N and TRACEN-N logic, it does cross-band now.

Many other small bugs fixes and enhancements.

Command Alias for CLI and Telnet access.

Integration between L2 Worm Router and NETROM increased (not completed).



See README.1ST file for release specific information.

Web Server enhancements.

PING command.

Telnet out command on CLI.

Command structure reorganization, command security.

NETROM Alias recognition.

Optional Recover from AGWPE failures.

Digiplex will not start a second instance of itself on the same machine.

Prompt fixed and interruption of commands.

TELNET.ALIAS consolidated into CLI.ALIAS


See the README.TXT file of this distribution to see changes made.


See the README.TXT file of this distribution to see changes made.


See the README.TXT file of this distribution to see changes made.


Disclaimer and License Statement


DIGIPLEX is free for radioamateur and experimental uses, commercial use requires written permission from the author. The author bears no liability for damages related to the usage of this program nor guarantees the proper functional behaviour. I could certainly be more sophisticated in legal terms, but in a nutshell use it at your own risk.

Publicly available information has been used to understand the requirements, specially the AGWPE TCPIP Interface (AGWSockInterface.DOC by G.Rossopoulos SV2AGW) and the “AX.25 Amateur Packet Radio Link Layer Protocol” (AX25.DOC), all code used to implement this program comes from my own development.

I’ve used the UIView32 Version 1.3 by Roger Baker G4IDE documentation as a reference to the main features to be implemented in order to support APRS (or UIView if you prefer), don’t really think I’m violating the program license in any way I could see doing that. Please note that UIView32 has a very good digipeater implementation on their own and it does support AGWPE too, so users interested on a “full APRS” operation should get it anyway.

The scheme to interoperate with FlexNet nodes is strongly based on the work of IZ5AWZ (author of the AWZNode Linux program) which in turn had been strongly influenced by the work of PE1RJA and OH2BNS.

If you need support, have suggestions, encountered some bug or just are willing to provide feedback drop me a note at:


AX.25:   [email protected]#ADR.BA.ARG.SOAM

Inet:    [email protected]

[1] Named L2XDIGI on the early releases of the program.

[2] For historical reasons the term “Interface” and “Listener” are used as synonims through the manual.