Table of Contents

 

Abstract 1

What is this program for? Audience. 2

Installation. 4

Pre-Requisites. 5

Verification. 5

Functional Description. 6

Configuration File (DIGIPLEX.INI) 7

Listener Configuration. 10

Usage. 11

Distributing Resources. 11

Known Bugs & Pending. 12

“Normal” Mode. 12

APRS Compatibility Mode. 13

Layer 2 Worm Digipeater 15

Description. 15

Listener 16

Routes. 16

Smart Mode. 17

Functional Description. 17

Troubleshooting. 17

Can not establish communication with AGWPE. 18

Does not operates correctly as a digipeater 18

A Defined Listener doesn’t seems to work. 18

Throughput of the digipeating process is slow.. 19

Acknowledgements. 22

Version Information. 23

Disclaimer and License Statement 24

 

 

Abstract

 

DIGIPLEX[1] is a Windows 95/98/NT executable implementing a cross port AX.25 Layer 2 Repeater (Digipeater) for the AGW Packet Engineâ. a 32 bits AX.25 packet 32 bits 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.

 

Also, an experimental support to digipeat AX.25 frames across TCP/IP connections is introduced, it uses the L2 Worm Protocol and it is described in detail later in this document (see Layer 2 Worm Digipeater).

 

DIGIPLEX uses the newly available TCP/IP API of AGWPE 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.

 

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 ).

 

Installation

 

 

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

• UnZip the distribution file DIGPLXnn.ZIP (nn=version) into a directory of your choice (i.e. C:\DIGIPLEX).
• Edit the entries on the provided DIGIPLEX.INI file or create a new one using it as a template, the main entry to modify will be

 

IP_ADDRESS=nnn.nnn.nnn.nnn

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=127.0.0.1 (see the Troubleshooting section for further details).

 

CALLSIGN=XXXXXX-nn

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).

 

[LISTENER] Section

One entry in the form

{CallSign}={PortIn},{ALIAS}

Per repeater listener required (i.e. LU7DID-1=1,ABROWN[2])

 

 

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

 

 

 

 

Pre-Requisites

 

The AGWPE version required is 2000.10 or later, 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

 

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.

 

 

Verification

 

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

 

[TCPIPINTERCONNECT]

ENABLE=1

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

·        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).

The program inspect the traffic over the defined ports of each listener defined ([LISTENER] 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 opposite port from where the frame was originally heard (heard on Port IN resend thru Port OUT, heard on Port OUT resend thru Port IN, if  Port IN = Port OUT the frame is resent the the same port it was heard originally).

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 listener 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)

 

Most of the 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 could 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:

 

Parameter	Description
[DIGIPLEX] Section	Mandatory
IP_ADDRESS	Defines the IP address of the machine where AGWPE will be found (default 127.0.0.1)
TCP_PORT	Defines the TCP port used to communicate with AGWPE (default 8000).
DEBUG	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.
TRACE	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!!).
CALLSIGN	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).
[BEACON]	Only required if Beacon Desired
ID	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	Text to sent thru the beacon
EVERY	Elapsed in mSecs between successive broadcasts of the beacon (0 will disable the beacon).
VERBOSE	If YES a list of all L2 Digi callsigns and serviced ports is added to each broadcasted beacon message.
[LISTENER] Section	Mandatory
One entry per listener in the general format CallSign-SSID={Port},Alias,{APRS},{TCP},SMART	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 TCP token is optional and enables the listener to act as an end of a L2 Worm Digipeater. The SMART token activates an special hop-to-hop ack protocol across the digi.
[WORM.ROUTES]	Optional (only if TCP Listeners had been defined)
CALLSIGN-SSID=Port,IP_Address{:Port},Password,MinHour,MaxHour	Specify a route to the remote digipeater CallSign-SSID to be established over a TCP/IP connection with IP_Address:Port
[APRS] Section	Optional (only if APRS compatibility is desired)
ALIAS	Comma separated list of all APRS destinations accepted by the digipeater in APRS compatibility mode (ej. WIDE,NARROW).
SUBALIAS	Indicates whether Alias replacement takes place (YES) or don’t (NOT or not informed).
UI_ONLY	Indicates whether UI frames only are allowed on APRS compatibility mode.
WIDEN-N	Activates (YES) or deactivates (NOT or not informed) the WIDEN-N multihop APRS mode.
TRACEN-N	Activates (YES) or deactivates (NOT or not informed) the TRACEN-N multihop APRS mode.
UIFLOOD	Indicates the destination id to be used for the WIDEN-N mode (default WIDE)
UITRACE	Indicates the destination id to be used for the TRACEN-N mode (default TRACE)
[APRS_ALIAS] Section	Optional (only if APRS compatibility is desired)
ALIAS=SUBSTITUTION	If SUBALIAS=YES this section list all substitution to take place when in APRS compatibility mode.

 

 

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 I use (included in the distribution file).

 

[DIGIPLEX]

 

IP_ADDRESS=127.0.0.1

TCP_PORT=8000

DEBUG=NOT

TRACE=1

CALLSIGN=LU7DID-3

 

[CLI]

ACTIVE=YES

TIMEOUT=120000

PROMPT=DIGIPLEX:

BYE=GoodBye!

 

[BEACON]

ID=ID WIDE

TEXT==3448.00S/05823.90W *** Digipeater Beacon Text ***

EVERY=240000

VERBOSE=YES

 

[APRS]

ALIAS=WIDE,NARROW,VIA

SUBALIAS=YES

UI_ONLY=NOT

WIDEN-N=YES

TRACEN-N=YES

UIFLOOD=WIDE

UITRACE=TRACE

 

[APRS_ALIAS]

WIDE=GBA

NARROW=ABROWN

 

[LISTENER]

LU7DID-3=1,TESTDG,APRS,SMART,ROUTER,TCP

 

[WORM.ROUTES]

LU7DID-1=1,44.153.48.33:8000,'',00,24

Listener Configuration

 

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

 

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

 

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.

 

i.e.

The [LISTENER] section states

 

DIGI1=1,LU7DID-1

DIGI2=2,LU7DID-2

 

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

 

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.

 

Nothing prevents to define more than one listener per physical AGWPE port, each listener will react only to frames which includes them on the VIA Path.

 

Usage

 

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.

 

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:

 

• Single Machine

 

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.

 

• Home LAN

 

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.

 

Known Bugs & Pending

 

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

·        Erratic Failure on AGWPE when using the “Smart” mode at the end of connections or failures to establish a link.

 

“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:

 

[LISTENER]

LOCALD=1,1,LU7DID-9

 

While a listener entry supporting APRS

 

[LISTENER]

ABROWN=1,2,LU7DID-1,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:

 

• ALIAS.

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:

• The CallSign+SSID of the digipeater replaces the APRS alias.
• The “Sent Bit” is set to “1” (already digied).
• The Alias is added at the end of the list.

 

• SUBALIAS

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.

 

• WIDEN-N

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.

 

• TRACEN-N

Similar to WIDEn-m

 

• UI_ONLY

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 2 Worm Digipeater

 

The program incorporates the possibility, on experimental grounds, to digipeat frames across a TCP/IP connection using the L2 Worm Digipeater Protocol devised for this program.

 

Description

 

When a digipeater listener is enabled also as a TCP L2 Worm Digipeater (adding the “TCP” token on the listener definition) for each frame the listener sees on the radio port directed to it coming from the first radio port indicated on the listener definition it passes the frame to the L2 Worm Digipeater Router.

 

The router algorithm inspect if there is another digipeater indicated in the path which still has not been used (Has been digipeated bit in 0) and if so try to find a TCP/IP route to it.

 

If a route is found a TCP/IP connection is attempted with the remote digipeater as indicated in the [WORM.ROUTES] section and the frame sent to it.

 

All frames that the router is unable to process are digipeated normally over the radio port as if the TCP L2 Worm Digipeater were inactive.

 

The TCP L2 Worm Digipeater will actually attempt to connect the AGWPE running at the other end of the TCP route and deliver the frame thru the indicated port.

 

If an answer is generated by the frame digipeated at the other end it will follow a reverse path over the other end listener which in turn will create a TCP/IP connection to our AGWPE which in turn will digipeat the frame creating a fully transparent connection across both ends.

 

Please, note that for this mode to operate the other end has to be enabled to digipeat using this mode and has to have us defined with a consistent route.

 

All types of data exchanges possible over AX.25 are supported, that includes NET/ROM, Unproto connections (i.e. APRS) and TCP/IP over AX.25.

 

For further information on how the frames are sent across the TCP IP connection see the “Raw Frame” AGWPE WinSock API format.

 

The port used at the other end of the connection is the one stated on the relevant entry at the WORM.ROUTE entry for the remote node.

 

 

 

 

 

 

 

 

Example   If a station LU1BUV wants to start a connection with LU7DID-2 over the path supported by the digipeaters LU9DGN-1 and LU7DID-1 (both ends of a L2 Digipeater Wormhole) the connection will be started as if two normal digipeaters were involved.   C LU7DID-2 via LU9DGN-1 LU7DID-1   The digiplex program servicing the LU9DGN-1 listener should have a WORM.ROUTE definition such as LU7DID-1=1,nnn.nnn.nnn.nnn:8000,,00,24 (or similar)   The TCP L2 Worm Digipeater at LU9DGN-1 having a route to LU7DID-1 will open a TCP/IP connection with it and pass the frame (using a Raw frame mode) to the AGWPE at the other end (with all the “digipeat” bits consistently set). The frame will appear over the radio port as:   fm: LU1BUV  to: LU7DID-2  via LU9DGN-1 LU7DID-1* <SABM>   upon acknowledgement LU7DID-2 will generate a <UA> frame such as   fm: LU7DID-2 LU1BUV via LU7DID-1 LU9DGN-1 <UA>   The listener at LU7DID-1 will recognize this is a frame to be directed over the “worm hole” (because it has a route to LU9DGN-1 with it) such as   LU9DGN-1=1,mmm.mmm.mmm.mmm:8000,,00,24   and will connect with the AGWPE at the other end and send the frame. The rebroadcasted  frame will be received at LU1BUV as   fm: LU7DID-2 LU1BUV via LU7DID-1 LU9DGN-1* <UA>   Please note that neither LU1BUV nor LU7DID-2 are aware at all of the L2 Worm digipeating mechanism, they operate just like over a regular pair of L2 AX.25 digipeaters.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Listener

 

Any defined AX.25 digipeater listener, as defined on the [LISTENER] section could be enabled to also operate as a L2 Worm Digipeater at the same time adding the clause “TCP” to the listener definition ([LISTENER] section).

 

Be aware that a unique TCP port must be used for each listener and all frames received thru that port will be digipeated indicated radio port on the listener only.

 

Routes

 

Routes to other L2 Worm digipeaters are indicated at the [WORM.ROUTES] section, each potential remote digipeater with an entry following the format:

 

CALLSIGN-SSID=PORT,IP_ADDRESS{:PORT},PASSWORD,HOURMIN,HOURMAX

 

Port is optional and if not indicated it’s assumed as 8000 by default. The Password is a field for future implementation and HourMin/HourMax controls the windows where this mode of operation is allowed.

 

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:

 

• The frame is internally transposed and redirected into a bogus internal call which is registered for AGWPE, so the calling station actually establish a connection with that bogus call instead of the original destination, this is transparent to the caller station.
• All frames answered by that bogus call are manipulated by the digipeater to appear as coming from the original destination (including the reverse path of digipeaters indicated).
• At the same time a connection is started with the destination on behalf of the caller (Callsign-(15-SSID)).
• Once both sides of the connection are established data in one direction is bridged into the other direction.
• Care is taken to manage the upstream and downstream path of digipeaters originally indicated.

 

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

Troubleshooting

 

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

 

• Can not establish communication with AGWPE.
• Doesn’t operates correctly as a digipeater.
• Throughput of the digipeating process is low.

 

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.

• Verify the IP Address of the machine AGWPE is running into, ensure that IP Address is the same than stated on the DIGIPLEX.INI file.
• Verify the TCP Port stated on DIGIPLEX.INI is 8000, or better still, remove the sentence (in order to force the default, which is 8000).
• Ensure there are connectivity between the machine where DIGIPLEX is running and the one AGWPE is running (if different machines), ensure the TCP/IP stack is properly configured and the loopback IP Address (127.0.0.1) is usable (if on the same machine).

 

 

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

 

CallSign-SSID={Port},Alias

 

i.e.

LU7DID-1=1,ABROWN

 

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.

 

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.

 

 

 

Acknowledgements

 

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 digi 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.

 

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

 

 

• Version 0.1 (Beta)

Initial release. Basic functionality. Distributed for initial evaluation.

• Version 0.2 (Beta), internal.
• Version 0.3 (Beta), internal.
• Version 0.4 (Beta), internal.
• Version 0.5 (Beta), internal.
• Version 0.6 (Beta), internal.
• Version 0.7 (Beta), internal.
• Version 0.8 (Beta), internal.
• Version 0.9 (Beta)

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

• Version 0.91 (Beta)

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

• Version 0.92A (Beta).

Added extended Beacon information (VERBOSE).

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

• Version 0.95A (Beta).

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.

• Version 0.97A (Beta)

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

Changed the Smart algorithm.

• Version 0.98A (Beta)

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

Several performance improvements.

Countless bugs removed.

 

Renamed into Digiplex Version 0.5 Beta

 

• 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).

 

• Version 0.6

Pseudo L3 Layer (Router implemented).

 

• Version 0.61

Pseudo L3 Layer improved.

 

• Version 0.62

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.

 

 

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.

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

 

AX.25:   LU7DID@LU7DID.#ADR.BA.ARG.SOAM

Inet:    colla@pec.pccp.com.ar