DigiPlex
Version 0.66 (Beta)
A cross-port AX.25 L2 Digipeater program and NET/ROM Node
for the
SV2AGW’s AGW Packet Engine
by Ing. Pedro E. Colla
(LU7DID)
Adrogue – Buenos Aires - Argentina
Table of Contents
What is this program for? Audience.
Configuration File (DIGIPLEX.INI)
Connection Security Configuration
Local Connections using Worm Routes
Can not establish communication
with AGWPE
Does not operates correctly as a
digipeater
A Defined Listener doesn’t seems to
work
Throughput of the digipeating
process is slow
The GUI dialog appears right on
Start, Nothing seems to Work.
Using the NETROM/Digiplex nodes
Discussion of the Program Modes.
Suitability of a Wintel Box to
operate as an Infrastructure resource.
Disclaimer and License Statement
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.
The program could be used also as a Layer 3 Router
capable to operate with the NET/ROM protocol and it’s own protocol (DIGIPLEX)
(see Layer 3 Router).
A Telnet Server is implemented to optionally allow
access from TCP/IP connections with restricted privileges.
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 .
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 two schemes for routing; NET/ROM and
DIGIPLEX.
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:
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.
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.
*** 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
[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.
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 ).
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). |
|
HOSTNAME |
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.. |
|
LOGIN |
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). |
|
PASWD |
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. |
|
[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, VIAPath |
Specify a route to the remote
digipeater CallSign-SSID to be established over a TCP/IP connection with
IP_Address:Port If the “remote” AGWPE (the one
to connect at the other end of the Worm, restrict machines from other LANs (or
even restricts applications to run outside the machine where it runs) a login
process has to be made. Digiplex assumes an userid with
the CALLSIGN of the caller (without SSID) has ben setup at the other end
(uppercase) and with password equal the one stated on the route. If no
password is given the login process is not performed. VIAPath will allow NETROM
broadcasts to automatically be sent over this Worm route with an additional
VIA Path (to increase it’s range at the destination). |
|
[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. |
|
[ROUTER] Section |
Optional (only if Layer 3 Routing
is desired) |
|
ENABLED=YES|NOT |
Defines whether or not Layer 3
Routing is Enabled or Not |
|
NETROM=YES|NOT |
Defines whether or not Layer 3
Routing is Enabled or Not |
|
DIGIPLEX=YES|NOT |
Defines whether or not Layer 3
Routing is Enabled or Not |
|
DIGI=YES|NOT |
Defines whether or not Layer 3
Routing is Enabled or Not |
|
L3RTTMIN |
Defines the minimum RTT to be
considered (in milliseconds) |
|
L3RTTMAX |
Defines the maximum RTT to be
considered (in milliseconds). Should be 600000 (600 secs) |
|
L3RTTINI |
Defines the initial RTT to be
considered (in milliseconds). Currently used as the default RTT for NET/ROM
nodes. |
|
L3HOP |
Defines the maximum number of
hops allowed on a routing. |
|
MASTER |
Defines the master cycle time for
broadcast routes and nodes information (in milliisecs). |
|
PORTMASK |
NOT USED |
|
L3POLL |
NOT USED |
|
L3UPDATE |
NOT USED |
|
PUBLISH=YES|NOT |
Routes to Neighboors are
published if YES, only local routes to be broadcast if NOT |
|
LOADROUTE=YES|NOT |
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) |
|
[L2WORM] Section |
Optional, see Layer 2 Worm Digipeater |
|
ENABLED=YES|NOT |
Enables the L2 Worm Router |
|
TIMEOUT |
Amount of time the socket will
be allowed to stay inactive before to be closed. |
|
BROADCASTNETROM=YES|NOT |
Will enable the NETROM router to
broadcast NODES (routes) frames over all active Worm
connections. |
|
[NETROM.APPLICATION]
Section |
Optional, see NET/ROM Managed Applications |
|
[HTTP] Section |
Optional |
|
[TELNET] Section |
Optional, See Telnet Server |
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).
[DIGIPLEX]
IP_ADDRESS=127.0.0.1
TCP_PORT=8000
DEBUG=NOT
TRACE=1
HOSTNAME=myhost.domain.org
CALLSIGN=LU9DGN-1
LOGIN=MYUSER
PASWD=MYPASW
[CLI]
ACTIVE=YES
TIMEOUT=120000
PROMPT=DIGIPLEX:
BYE=GoodBye!
[BEACON]
ID=ID
WIDE
TEXT==3448.00S/05823.90W
*** Digipeater 145.15<->431.20 LU7DID-1 (Adrogue,BA,Argentina) ***
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]
LU9DGN-1=1,TMPY,APRS,SMART,ROUTER,TCP
LU9DGN-7=2,TMPY,APRS,SMART,ROUTER,TCP
LU9DGN-8=3,TMPY,SMART,ROUTER
[WORM.ROUTES]
LU7DID-3=1,44.153.48.3:8000,'',00,24,
[NETROM.APPLICATION]
BBS=LU9DGN,MIKE
[ROUTER]
ENABLED=YES
PORTMASK=255
NETROM=YES
DIGIPLEX=YES
DIGI=YES
L3RTTMIN=1
L3RTTMAX=600000
L3RTTINI=30000
L3HOP=8
L3POLL=1
L3UPDATE=3
MASTER=60000
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.
The overall format of the entries at the LISTENER
section (one entry per listener) is as follows:
{CALLSIGN-SSID}={Port},{ALIAS},[Optional Directives]
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.
*** Warning *** The listeners should use
the same callsign than the used at the Listeners, and the listeners should
use all of them the same callsign (with different SSIDs). A good practice
would be to set the CALLSIGN directive with the same callsign-ssid of the
first listener. If this condition is not met the behaviour of the L3/L4
routers will be erratic.
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.
When
the “SMART” directive is added on a Listener configuration the “hop-to-hop ack”
or intelligent digipeating is enabled on it.
i.e.
LU7DID-1=1,ALIAS,SMART
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).
For
further information on the functional aspects of the SMART mode see Smart Mode.
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).
i.e.
LU7DID-1=1,ALIAS,ROUTER
When
the “TCP” directive is added on a Listener configuration all frames are
inspected against the possibility to be broadcasted thru a L2 Worm connection.
i.e.
LU7DID-1=1,ALIAS,TCP
Actual
operation over a L2 Worm connection will depend on the frame meeting the the
conditions for this route to happen and the existence of valid routes (See Layer 2 Worm Digipeater for further information).
All
directives (TCP,ROUTER,SMART) could be combined on a single listener
configuration
i.e.
LU7DID-1=1,ALIAS,TCP,ROUTER,SMART
The
order of the directives is not relevant.
Digiplex
saves periodically a snapshot of it’s routes (both Digiplex and NETROM) on the
ROUTES.INI file.
The
format of the file is as follows:
CALLSIGN-SSID=PORT,NODE,CONTROL,RTT,HOPS,ALIAS,LOCKED,OBS,QUALITY,VIA
The
content of the ROUTES.INI file is only read back by Digiplex upon startup if
the LOADROUTE directive is set to YES on the ROUTER section.
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.
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.
·
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.
·
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).
·
When
both the Layer 3 Digiplex and NETROM are enabled routing problems might occur.
·
Racing
conditions on the Internode communication between DIGIPLEX nodes, high volumes
of data interchanged (still it’s not a loop, it actually stops…… eventually hi
hi).
·
The
TT (Total Time) computed as the SNTT between internodes and RT (Network
Response Time) assumes strange results when a mix of NET/ROM and DIGIPLEX nodes
are exchanged, as a result downstream neighboor nodes could show a better
routing time than upstream nodes and thus produce routing loops.
·
Ocasionally,
the internode exchange between DIGIPLEX nodes is maintained using regular AX.25
frames (Pid $F0) instead of Layer 3 frames (Pid $CF); the node with the problem
is interpreted by it’s neighboors as a regular user and it’s internode frames
ignored.
·
NET/ROM
RTT’s are not actually computed but considered as the initial RTT as stated on
the DIGIPLEX.INI file; this might lead to strange routes selections sometimes.
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.
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:
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}
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.
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.
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 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{:TCPPORT},PASSWORD,HOURMIN,HOURMAX
TCP 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.
*** Important Notice *** Please be aware that the following routes are provided
just as an example and had been setup as a temporary test environment for experimentation
and learning purposes, it does not imply any commitment for availability
nor any guarantee of level of service and they could be removed or changed
at any time without any prior warning. The usage of them might conflict
with your local regulations that must be checked before to make any use of
the configuration.
Currently the routing thru the Worm is somewhat arcane to understand initially, at this point of the development the focus is to make it work reliably; later as development progress some user friendliness will be added to it (I hope!).
The following is a practical example of the test
environment between Paul (N1OTX) in Ma (USA) and me (LU7DID) in BA (Argentina).
Paul’s Worm configuration
N1OTX-7=1,BROCK,TCP,ROUTER,SMART
The routes he defined
LU7DID-1=1,lu7did.dyndns.org:8000,’’,00,24
LU7DID-7=2,lu7did.dyndns.org:8000,’’,00,24
LU7DID-8=3,lu7did.dyndns.org:8000,’’,00,24
LU7DID-9=4,lu7did.dyndns.org:8000,’’,00,24
So he defined one route for each of my radio ports (including
the loopback port, 4).
I do have a dial-up on demmand configuration on my
LAN which updates the current IP address I got thru the dyndns.org service
where I have several “virtual domains” registered under my name. So, If I’m
online lu7did.dyndns.org reflects my IP address.
On my station I have the following configuration
LU7DID-1=1,ABROWN,TCP,ROUTER,SMART
LU7DID-7=2,ABROWN,TCP,ROUTER,SMART
LU7DID-8=3,ABROWN,TCP,ROUTER,SMART
LU7DID-9=4,ABROWN,TCP,ROUTER,SMART
and the Worm routes I’ve defined are
N1OTX-7=1,pauland.ne.mediaone.net:8000,’’,00,24
Paul got a quasi-static IP address which changes
once in a while, so for all practical purposes he’s online all the time.
With this configuration the following scenarios
where successfully tested.
C 4 WHIT LU7DID-9 N1OTX-7
This started a connection with the node WHIT on
Paul’s area from my station (note the connection was initiated thru my loopback
port using the listener for it).
Then connected as an user to a local NETROM node
(LU3DY-4) I tested the following
connection
C 1 WHIT LU7DID-1 N1OTX-7
In this case the connection with the same node
(WHIT) was performed first thru the radio channel served by my port 1 (listener
LU7DID-1) which also corresponds with the Port 1 of the particular NETROM node I
was using.
Also, the opposite path were tested successfully;
while logged on WHIT I fired the following connection to another local NETROM
node (LU6DK-4) as
{WHIT} C LU6DK-4 N1OTX-7
LU7DID-1
The most difficult issue to understand initially
(and where some user friendliness has to be added) is to understand which
callsign-SSID of which listener has to be used; this is perhaps more difficult
to understand for the sysop of the node himself. Users on the radio channel
just sees one listener (the one servicing the radio channel they are working
in) so it should be more intuitive (hope so).
At this point of the development both sides has to
have a fully configured and bidirectional routing setup (static routes defined)
in order for the scheme to work.
Bottom line of this kind of connection is that
without any special equipment, software or configuration any user that could
reach me could reach anybody on Paul’s area and viceversa in a completely
transparent way. Nothing prevents this link to be used for any purpose a radio
path could be used for.
This example is aimed to explain the usage over the
Internet, it’s selected on purpose because it reflects actual and tested
configurations; but nothing prevents the same concept and mechanisms to be used
on ANY valid TCP/IP route, and that includes completely radio based TCP/IP
links.
The main benefit I see is the implicit routing made
available by this mode; a given connection could be established across several
hops controlled by TCP/IP routing (i.e. a backbone) interconecting remote LANs
in a completely transparent way for the user.
The
minimum requirement for a Worm connection to occur is to have a frame where the
current digipeater is the next to be involved, there is a “next” digipeater and
that digipeater is marked as a Worm route on the [WORM.ROUTES] section of
DIGIPLEX.INI.
If
the above conditions are not met the Worm router will not handle the frame.
However,
nothing prevents the existence of an arbitrary number of digipeaters before the
pair that activates the Worm, after it or both.
In
that way, a station that could not have direct visibility to a Digiplex node
could reach it using a digipeater (that might be either a Digiplex digipeater
or just a plain dumb digi) and eventually could extend his/her reach at the
“other side” of the worm connection indicating additional digipeaters.
I.E.
Assume
there is a Worm connection between LU7DID and N1OTX; N1OTX has one radio port (port
1) where a listener has been designated as N1OTX-7. In the other hand LU7DID
has 3 radio ports designated as LU7DID-1, LU7DID-7 and LU7DID-8.
A
station called LU9DGN wants to access the station K1UGM, but neither he could
access LU7DID nor at the other end N1OTX could reach K1UGM; the connection
could be established if LU9DGN makes the connection using the normal digipeater
LU6DK-4 while in the other end the node could be reach using the digipeater
WHIT.
The
connection that LU9DGN should attempt is
C K1UGM via
LU6DK-4,LU7DID-1,N1OTX-7,WHIT
Please
note that care has to be exercised with the SSID of the listeners to be used,
the listener at LU7DID must be the one that could talk with LU6DK-4 while the
listener at N1OTX must be the one that could talk with WHIT.
This
connection order will trigger the following events:
·
LU9DGN
will send the connect frame (SABM).
Any
answer will just follow the reverse path once the connection had been
established.
All
examples points to the usage of Worm routes by stations other than the one
running the node, still this kind of operation is possible.
The
following conditions has to be met:
·
AGWPE
has to have at least one LoopBack port defined.
I.E.
LU7DID
wants to connect the node WHIT using the Worm connection with N1OTX. The
listener LU7DID-9 is defined to manage the loopback port of AGWPE, the other
end of the connection is managed by the N1OTX-7 listener.
So
the connection to be attempted is:
C WHIT via
LU7DID-9,N1OTX-7
If the security configuration of any of the AGWPE involved into establishing a Worm connection is enabled (as discussed in Configuration File (DIGIPLEX.INI)) then the connecting digiplex program (the other end) has to provide a login and password in order to be allowed to interoperate and establish the Worm connection.
The following conditions are then to be fulfilled:
· If security is enabled an Userid equals to the Callsign of the other end without SSID has to be defined (uppercase).
· The password has to be stated on the Worm route.
i.e.
Following with the example on a previous section assume N1OTX established a security setting of only allowing connections from “My Computer”, so any connection from a different machine has to execute a login.
In order to allow connections from LU7DID-1 an userid “LU7DID” has to be defined (callsign without SSID) with any password (i.e. “anypass”).
The route to N1OTX has to be established as:
N1OTX-7=1,pauland.ne.mediaone.net:8000,anypass,00,24
In order for the worm connection to successfully be established.
The digiplex program implements a variety of routing algorithms; as per the beta releases all of them are experimental and routing problems might occur; the routing capability is in general enabled with the ENABLED clause on the ROUTER section of the DIGIPLEX.INI file.
If
ENABLED=NOT both the SMART mode and L2 WORM features 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 and eventually to enable
interconnection of LANs over TCP/IP connections.
When
ENABLED=YES the program will behave depending on the configuration as:
The
modes will be seen with more detail on the incoming sections.
The DIGIPLEX program will announce itself to the network as a NET/ROM compliant node thru all listeners where the clause “ROUTER” is indicated.
The
implementation will:
The
implementation is still on it’s early stages so full compatibility with all
NET/ROM implementations is yet to be tested; all tests done so far were done
with G8BPQ neighboor nodes.
The
NETROM clause on the ROUTER section enables the NETROM router.
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 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:
NICKNAME=CALLSIGN-SSID,ALIAS
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; it’s meaningless using a Digiplex routing scheme since the
application could always be accessed directly thru an AX.25 connection or thru
a chain of digiplex repeaters.
By default the NETROM routes are broadcasted thru
all the Listeners where the directive “ROUTER” is indicated. The NETROM routes
uses an UI frame with PID=0xCF adressed to the Id ‘NODES-0”.
NETROM routes could also be broadcasted thru active
Worm routes if the directive BROADCASTNETROM=YES is indicated in the L2WORM
section of the DIGIPLEX.INI configuration file.
The reach of the broadcast could be extended if a
VIA Path is indicated on the Worm route adding the VIA Path information.
If the Worm route is not active at the moment the
broadcast takes place no attempt to activate it is made (in order to avoid
undesired activations of TCP/IP connections).
The digiplex router implements a new protocol for internode communication and route finding.
The
implementation will:
For
an in-depth discussion of the algorithms and criterias implemented on the L3
Digiplex Internode Protocol please refer to the protocol documentation.
The
implementation is still on it’s early stages and substantial work is still
pending on the algorithms to select routes and the computation of the RTT
meassurement.
The
DIGIPLEX clause on the ROUTER section enables the DIGIPLEX router.
Ideally,
the DIGIPLEX and NETROM routers could coexist on the same node that will
exhibit the dual behaviour; some outstanding bugs on the present level of
implementation prevents this to happen so unstable routes and loops could be
obtained when both routers are simultaneously active.
To a point the DIGIPLEX router is able to use “dumb” digipeaters not enabled for the digiplex protocol to route the “last hop” of a path.
At
the present this mode is still under development and the only noticeable effect
of it’s presence is the detection of digipeaters in the area.
Starting
on version 0.66 an optional Telnet Server had been incorporated to Digiplex.
The
server allow TCP/IP based connections to be served started from a Telnet client
over a TCP/IP circuit.
Two
separate ports could be enabled (independently), the monitor port (Port 8025 by
default) and the connection port (Port 8023 by default).
Even
if the local AGWPE could be accessed directly thru the Winsocks API from a
remote location over a TCP/IP and there are security mechanisms in place to
prevent unauthorized usage the access is still an “all or nothing” feature.
Users allowed to connect to the AGWPE could, eventually, perform any operation
the local sysop could which might be undesirable for a general audience.
The
Telnet server instead allows users to access the environment (with a prior
UserId/Password validation) and basically allowed to establish connections
using the CallSign-SSID the sysop assigned to them.
The
configuration of the Telnet server is made thru the entries at the TELNET
section of the DIGIPLEX.INI file.
Relevant
entries are:
·
ENABLED
(default NOT), enables the Telnet Server.
·
PORT
(default 8023) TCP port where the Telnet connection server will listen for
connections.
Valid
UserId and passwords are defined thru entries on the USERS section of the
USERS.INI file using the following format:
{USERID}=PASSWORD,CALLSIGN-SSID
The
CALLSIGN-SSID parameter will be used to start any connection from the Telnet
session, if omitted the USERID-0 will be used instead.
This
server will not require security validation to be accessed, once a connection
is made all activity on the radio ports is sent to all connected Telnet
clients.
No
activity could be made from the Telnet clients connected.
This
server will require UserId/Password to validate connecting Telnet clients, the
provided UserId/Password must match one of the entries on the users file
(USERS.INI).
Once
validated activity could be held from a Telnet Terminal, basically:
·
Connect
to other stations (the callsign-ssid to be used is sysop defined).
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.
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
The program allows connections to be made over radio to it and it provides a (rather rudimentary) interface to the user.
Still,
at this point of the development, the primary purpose of the Command Line
Interface is not related to the operation of the program but to the test and
debug process.
Current
commands not necessarily will survive to the late stages of development, it
could be protected or even could be removed.
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.
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, 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.
Please
note that to actually operate the node no connection to it is required.
Most
of the commands results would be self explanatory with the probably exception
of the “r” command; the format and meaning of the result will be:
<n> [*LHDFNX ]
Node(n:CALL-SSID) Call(Call:Alias) TT(NN) Hop(N)
The first value is the connection status with the station of the entry, it could be 0 (no connected), 1 (Trying to Connect), 4 (Connected) and 3 (Trying to Disconnect); usually reflects a value different from zero with neighboor DIGIPLEX nodes if any.
Follows
the control word which reflects the attributes of the entry and present status;
“*” means Internode link established (not necessarily now), “L” this is a
locked entry (coming from the configuration file) usually for configured
listeners, worm routes and NETROM managed applications. “H” if the station was
heard directly. “D” if heard or identified as a “dumb digipeater”, “F” FlexNet
Node, “N” Netrom Node and “X” Digiplex node.
Follows
the neighboor Node port, callsign and SSID.
Folows
the CallSign and Alias of a resource that could be routed thru Node.
TT
means “Total Time” and it’s the sum (expressed in milliseconds) of the RTT
between this node and the one that it’s a candidate route to it plus the
reported propagation time to the final destination.
Hops
means how many network hops are required to reach this destination.
A couple of paragraphs related to FlexNet compatibility.
This program has been designed as an integration tool;
it tries to implement it’s own protocol (which is optimized for certain
scenarios) but at the same time tries to use available resources such as
NET/ROM nodes or dumb digipeaters in the area.
I would like to do the same with FlexNet nodes; not
to compete with them, not to emulate them, but to integrate to a meaningful
point with them.
But, unfortunately, to find out information about
the FlexNet internode protocol had been extremely difficult to find, actually
impossible to find so far.
So even if the program “architecturally” is ready to
integrate FlexNet routes in the future no implementation had been done so far
on that regard.
Actually, it’s highly probable that FlexNet nodes
would be seen as “dumb digipeaters” and used as such (far below the potential
of the FlexNet capabilities); but this scenario wasn’t actually tested so far
due to the lack of a suitable FlexNet network in my home area.
If at some point in the future I could get more
information about FlexNet I would gladly try to integrate or to interoperate
with it.
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).
In
case communication with AGWPE could not be established the following
configuration should be checked:
·
Ensure
AGWPE is up and running.
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 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.
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.
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.
The NETROM and Digiplex nodes, when enabled, will operate from the user perspective in a slightly different way than conventional NET/ROM nodes; this happens because of the very own nature of the AGWPE platform and the concepts inherent to the digiplex program.
The
digiplex node needs not to be contacted by the user in order to operate the
network routing facilities; the lack of a “C” command (Connect) will look both outstanding and strange for operators
used to the conventional NET/ROM nodes.
A normal AX.25 connection could
be initiated with the node to access the CLI (Command Line Interface) of it;
however it is useful only to operate the node and to see the actual status of
routes and heard stations. No connection with the node is needed to access
network resources thru it. The actual commands available will depend on the
configuration of the node. The ? or h commands will tell which commands are
available with a short description of them.
The Digiplex node has to be
stated as a digipeater instead of the most common approach that is to connect
to the node and then connect to the destination.
I.E.
If you want to connect with the NET/ROM node LU6DK-4 thru the
Digiplex node LU7DID-1 you connect as:
C LU6DK-4 via LU7DID-1
The digiplex router needs to be enabled and the
involved port be defined as “SMART” for this kind of routing to operate.
The Digiplex node automatically will route the
connection with the destination node using NET/ROM and “hop-to-hop ack”.
The Digiplex Node will be
shown as yet another NET/ROM node so it could be contacted either thru the
callsign-ssid or alias published to neighboors.
The applications managed by
the Digiplex node will be broadcasted as a NET/ROM resource, so it could be
accessed from other NET/ROM nodes either connecting to the published
callsign-ssid or alias.
You don’t need a network to
do that, just connect the application using a normal AX.25 connection. AGWPE
operates as an implicit multiport switch.
The Digiplex node will not involve
routing when a single digipeater is stated, it will operate as a smart
crossport digipeater.
When more than one
digipeater is stated each digiplex node will compute the best route to the next
digipeater to reach the final destination stated by the user on the originall
connection. If one or more digipeaters aren’t identified as Digiplex nodes the
node will normally broadcast the frame assuming those are “dumb” digipeaters
(of course, the actual connection will be established if the digipeaters do
exists).
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 L2 WORM
routing, the NETROM routing and the DIGIPLEX 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 L2 WORM mode is enabled
at the Listener level by means of the “TCP” directive. This mode takes precedence
over the other routing schemes. It operates when at least two digipeaters are
in the path, the current digipeater is actually one of the program defined
listeners (by SSID), it is enabled by L2 Worm routing (has the TCP directive)
and there is a route for the next indicated digipeater a the WORM.ROUTES
section of the DIGIPLEX.INI configuration file. If any of the above conditions
are not meet the frame is not managed by the L2 Worm router (actual management
will depend on other configurations). This mode is fully optional, if you don’t
plan to involve TCP/IP tunnel (worm) routes it doesn’t need to be enabled.
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 DIGIPLEX 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) and the DIGIPLEX configuration
has to be set to YES too. When those conditions are met that particular
listener will be enabled to broadcast periodically “XDIGI” frames, accept XDIGI
frames from neighboor, initiate/accept/sustain an Internode connection with
neighboor DIGIPLEX nodes and given the conditions are met use routing
information to transport information. The Digiplex mode works in a
substantially different way than the NETROM routing scheme.
When a listener on a node is
enabled for the DIGIPLEX mode frames with at least two digipeaters on the path
with the current being one of the enabled listeners are found the frame is pass
to the router. The router decides whether the 2nd (next) destination
could be reach directly or a better path could be found thru an intermediate
node; if that is the situation the additional (intermediate) node is added to
the path. If the next digi in the path is at the same time the best route then
the frame is digipeated as received. If no route is found to that digipeater
the frame is digipeated anyway as received (in the high hopes for this
digipeater to actually exist). Please note that if there is no a “next”
digipeater no Digiplex routing takes place and the program behaves as a
“normal” digipeater (with or without smart behaviour depending on the
configuration of the particular listener used). This mode is optional to the
extend discussed above.
Additionally, if the
destination of the frame is a known NETROM destination and the current
digipeater is one of the valid listeners and there is no “next” digipeater the
NETROM node is connected as an user and a “hop to hop ack” sequence started;
note that for this mode to operate the listened has to be SMART and NETROM
enabled even if this is a DIGIPLEX routing scheme (the first to enable the hop
to hop mechanisms and the second to allow Digiplex to know something about
neighboor NETROM nodes).
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), the
capability to run Worm routes across TCP/IP paths and some classical on-the-LAN
routing functions (NETROM and DIGIPLEX); 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 127.0.0.1
or 128.0.0.1 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
PING 127.0.0.1
If you get an answer such as:
Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Ping statistics for 127.0.0.1:
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
following:
Pinging 127.0.0.0 with 32 bytes of data:
Destination specified is invalid.
Destination specified is invalid.
Destination specified is invalid.
Destination specified is invalid.
Ping statistics for 127.0.0.0:
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.
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 with the L2
Worm router 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.
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.
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.
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.
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