DigiPlex
Version 0.73 (Beta)
A cross-port AX.25 L2 Smart Digipeater program and NET/ROM Node
for the
SV2AGW’s AGW Packet Engine
by Ing. Pedro E. Colla
(LU7DID)
Adrogue – Buenos Aires - Argentina
Table of Contents
What is this program for? Audience.
Configuration File (DIGIPLEX.INI)
Connection Security Configuration
Installation of the Web Interface
Command Line Interface Aliases
Can not establish communication
with AGWPE
Does not operates correctly as a
digipeater
A Defined Listener doesn’t seems to
work
Digiplex and the AR DX Cluster
Throughput of the digipeating
process is slow
The GUI dialog appears right on
Start, Nothing seems to Work.
Failure to interact with a NETROM
node delivering CTEXT.
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/ME/2000 executable implementing a cross port AX.25 Layer 2 Smart
Repeater (Digipeater) for the AGW Packet Engineâ.
a 32 bits AX.25 packet platform developed by George Rossopoulos (SV2AGW).
It’s purpose is to enable a given station to act as
a digipeater either on traffic over a single AGWPE defined port
or across different radio ports (frecuencies).
AX.25 frames heard in one defined port indicating
the callsign of the digipeater as a path will be transferred to the other
defined port as a digipeated frame and viceversa in a way that enables a full
two-way packet contact across (eventually) different ports.
It is intended to enable the communication of
stations operating on different AX.25 radio channels (at even different speeds)
in a transparent way just by routing the a given connection over the digipeater
program, in other words, the program could be seen as a simple AX.25 Layer 2
router or switch.
Since the operation is fully transparent any kind of
contact is supported, including network protocols such as NET/ROM or FlexNet as
well as TCP/IP.
The program could be used also as a Layer 3 Router
capable to operate with the NET/ROM protocol both to achieve enhanced
digipeater functions and to interact with neighboor NET/ROM nodes.
DIGIPLEX uses the newly available TCP/IP
API of AGWPE (WinSock API) and should run on any machine
AGWPE could run, you could download the latest version of the program as well
as the TCP/IP API related documentation directly from George’s home page at http://www.raag.org/sv2agw or http://www.elcom.gr/sv2agw .
Many packet operators are familiar with the concept of an AX.25 digipeater since this is a feature built into the AX.25 protocol itself and since forever.
A digipeater is a simplex, digital, repeater which
relay AX.25 frames between stations; several digipeaters could be chained (into
what is known usually as the “VIA” path), it has many uses being the most
obvious ones to extend the coverage of a given station or to take opportunity
of the privileged position of a particular station to extend the useful range
of a given station.
The digipeater concept is very simple and it’s also
simple to setup and operate one, actually many regular stations has their
software or hardware configured in a way that could operate as a repeater (the
setup is far more simpler than the one required for the distant cousin, a
voice/digital duplex repeater).
As simple as it is a digipeater has it’s drawbacks
also, the most obvious is the efficiency in terms of bandwidth (or effective
throughput speed) if you wish.
Since the frames are relayed entirely every
digipeater “hop” reduces the bandwidth efficiency (and thus the throughput) by
half, making impractical links over more than 2 or three hops (albeit the
protocol itself allows several more hops); this single factor has reduced the
actual usability of digipeaters very much and when greater distances or
coverage is required more advanced routing techniques (operating at Layer 3 or
4 such as NETROM or TCP/IP) are favoured.
In practice is very rare to see usages of more than
one hop except on very special situations and geographic configurations.
Still, with the proliferation of stations with more
than one radio port the desire (or need) for an station operating on one port
(radio channel) to hop over and link with an station in another channel do
appear.
In order to achieve that trick, beyond the scope of
a simple Layer 2 digipeater which operates on the same channel, more complex
setups are usually required, such as an AX.25 switch (like G8BPQ)
or other Layer3 and 4 implementations such as NET/ROM or FlexNet.
When more complex configurations than a simple-hop
router are needed the program implements also other schemes for transport and
routing such as an implementation of the
NET/ROM protocol and a simple MHEARD based routing scheme.
This program takes advantage of the multiport nature
of the AGW Packet Engine to implement a Layer 2 digipeater with
some additional (optional) features, in particular the capability to relay
frames from one radio port to other in a bidirectional way.
Then, stations operating at one radio channel could
“transparently” link with stations operating in another.
Nothing prevent this program to be chained across
“several” channel “hops” as long as (of course) there are stations running it
that could create such a route.
To operate using a digipeater over more than one
channel is not as inefficient as to do the same on the same channel, the
bandwidth is used once on each channel; still the throughput will reflect the
fact the frame is transmitted twice (or more).
It’s ideally suited to link channels where the speed
is different (i.e. 1K2 and 9K6) when the throughput effect for the slower side
is much less important, few issues has to be addressed and understood in order
to optimize such setup (some of the issues are covered in detail later in this
document).
Actually, nothing prevents to implement special
configurations such as two channels on different geographical regions linked by
a dedicated (high speed) link; still the routing has to be made manually
(stating the digipeaters of both ends of the high speed link).
The audience of this program should be composed by
anybody willing to experiment a little; more stable setups should be performed
by stations that having a multiport configuration and relatively good equipment
(or geo location) are willing to provide a connectivity service to their
neighboors.
Some
provisions has been made to make this program compatible with APRS (A Packet
Radio System), additional information could be found on the appropriate section
of this document (see APRS Compatibility
Mode ).
Warning - Notice
There are operating considerations when you use the
digipeater across ports that works at different speeds. Please refer to the
operation instructions before to implement that configuration.
To install the program the following actions has to
be performed:
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).
[INTERFACE] Section
One entry in the form
{Interface Name}={AGWPE
Port},{CallSign},{Alias}.{Quality},{.. flags}
Per repeater listener required
(i.e. ax1=1,LU7DID-1,,250,ROUTER,APRS,TCP,SMART)
Many other options might be required to enable or configure different aspects of the program operating behaviour, please see the appropriate sections of this manual for details.
The program doesn’t alter any system resource nor configuration, it could be removed just deleting the directory where it had been installed or by executing the automatically installed Uninstall program.
The AGWPE version required is 2001.10+ or later, it could work with versions starting with 2000.10+ (it won’t work with versions prior to that), so if you have a prior version or you are not sure what version you have just play safe and download a fresh version from SV2AGW’s Home Page
Note AGWPE versions prior to 2001.22 have a bug called “sleepy
frame problem” where erratically links got stuck and eventually reset due to lack of activity;
essentially frames sent by Digiplex were held inside AGWPE without being transmitted. This problem
severely impairs the activity as node and file transfers (such as BBS forwarding). Usage of AGWPE
2001.22+ is highly encouraged.
When used with versions prior to 2001.10+ (but higher than 2000.10+) some incompatibilities on the NET/ROM operation will be found, other functions of the program will not be affected.
The AGWPE has to have at least one loopback port
defined for this program to work.
The program itself could run on either Windows 95, Windows 98, Windows NT, Windows 2000 and (probably) on Windows ME, still, the main requisite is to have AGWPE up and running on the target platform you’re planning to use.
*** Important Notice ****
DIGIPLEX interacts with AGWPE using it’s TCP/IP API, that requires the Windows 95/98/NT TCP/IP stack to be configured and functional. However, this is not related to the AGWPE TCP/IP drivers (for Windows 95/98) which are essentially a way to allow the Windows TCP/IP stack to operate over AX.25 radio links, the AGWPE TCP/IP drivers do not need to be installed for DIGIPLEX to work properly. Beware that the AGWPE TCP/IP drivers requires registration to work after a trial period, for details about the registration please see George’s (SV2AGW) Home Page.
There is one operational mode of this program that MIGHT require the AGWPE TCP/IP drivers to be installed, and it is when you enable the “worm” mode on a given listener and wish to carry the connection over radio. The drivers are not required if you want to use the worm mode over other TCP/IP connections such as over the Internet.
The DIGIPLEX is an application that could not be
accessed directly by the user other than to shutdown it, it has to be
loaded initially and furthermore it will operate over the frames heard on the
designated ports without the operator intervention.
.
·
Load
and configure AGWPE, follow the intallation instructions for
that. Be sure the AGWPE.INI file has the following entry
[TCPIPINTERCONNECT]
ENABLE=1
·
Ensure at least one Loopback port is defined, this program will not
work without it.
·
Turn
off the AGWPE Security, it won’t be required unless your system is open to big
networks and you could configure it later. To do so go to AGWPE Setup
Interfaces/Winsock Interface Security and select the radio button “Accept
without Login from Anywhere”.
·
Test
AGWPE to be functional with any of the provided programs such as AGWTerminal
or AGWMonitor, if they refuses to work it’s highly likely that DIGIPLEX
won’t work either.
·
Load
DIGIPLEX, it should work transparently. In case of problems see the Troubleshooting section of this document.
The DIGIPLEX program is an AGWPE
compliant application program which implements an AX.25 Layer 2 Repeater
(Digipeater) as it’s core functionality.
The program inspect the traffic over the defined
ports of each listener[2]
defined ([INTERFACE] Section) and whenever it detects frames that has been
informed the callsign-ssid of the associated listener as a part of the path it performs the following activities:
·
It
sets the “Repeated Bit” to 1 on the AX.25 Frame.
·
It
resends the frame thru the interface owned by the callsign-ssid referred on the
AX.25 frame (SSID routing).
An
AX.25 Layer 2 Repeater (Digipeater) is a relatively dumb device, it doesn’t
handle the concept of a connection nor manage any detail about the handshake
between both final ends of the connection (that might include, albeit not
necessarily, other digipeaters in the path); as many frames are heard that fits
the relatively narrow criteria already stated are re-broadcasted.
Since the digipeater knows nothing about the nature
of the connection it could handle any sort of traffic, both connected and
unconnected frames; also, it could handle special frames such as the ones
typically used for NETROM or TCP/IP traffic.
Whether or not the digipeater rebroadcast a given
frame is strictly defined for the detection of it’s own callsign-ssid (as
defined on the entry of the INTERFACE section on the DIGIPLEX.INI
configuration file) with the “Repeated Bit” of the AX.25 set to 0 (not repeated
yet) and with no other digipeater stated on the frame with that bit also set to
0 (meaning that the digipeater is “hearing” a frame that has not been
“digipeated” yet on the proper sequence).
Other operating modes are also available (see “Smart” Mode ).
The most basic and primitive configuration needed by DIGIPLEX has been set with the short instructions given for the initial installation of the program, however some additional operation modes and configuration parameters should be stated as well.
This
file is not used for any other program nor affects in any way the overall
behaviour nor the operation of the Windows environment, it could be removed as
a part of the uninstallation of DIGIPLEX program withour any further consideration.
However,
if not properly configured it is unlikely that DIGIPLEX could
work at all (and in some cases it would drive it to fail, see Troubleshooting for details), so attention has to
be pay to the settings defined on it; also some undesired “on the air”
behaviour could be obtained if some parameters are improperly configured.
The overall format is that of any standard Windows .INI file, several section logically groups the configuration parameters of different aspects of the program as follows:
|
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. |
|
RECOVER {YES|NOT} |
Try to recover if initial
attempt to connect to AGWPE fails, default NOT. |
|
NODEPASS |
Password that will be required
for the sysop to Login into the node and have access to the SYS command. |
|
[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. |
|
[INTERFACE] Section |
Mandatory |
|
One entry per listener in the
general format Name=Port,CallSign-SSID,,{APRS},SMART,ROUTER Name is any user choosen name to
refer to the interface Please do note the double ,,
between the CALLSIGN-SSID and the optional tokens. |
A verification is made to avoid
conflicting definitions, the APRS token is optional and
enables the operation of the digipeater in APRS compatibility mode. The SMART token activates an
special hop-to-hop ack protocol across the digi. The ROUTER token activates
router functions on the interface |
|
[APRS] Section |
Optional (only if APRS
compatibility is desired) |
|
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 |
|
MHEARD=YES|NOT |
Defines whether or not simple
MHEARD based routing is Enabled or not. |
|
MASTER |
Defines the master cycle time
for broadcast routes and nodes information (in milliisecs). |
|
ALIAS |
Defines the Router default Alias
to be used. |
|
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) |
|
ROUTES |
Select the file where routes
will be saved, ROUTES.INI by default. |
|
NOTIMEOUT={YES|NOT} |
Includes (YES) or doesn’t
includes (NOT) the timeout value on NETROM SABM frames (default YES). |
|
[NETROM] Section |
Optional (only if Layer 3
Routing is desired) |
|
L3QUALMIN |
Minimum Quality accepted for
Broadcasts |
|
L3QUALDEF |
Default Quality |
|
L3OBSMIN |
Minimum Obsolecense accepted for
Broadcasts |
|
L3OBSMAX |
Obsolecense set initially |
|
L3QUALAPP |
Default Quality to be assigned
to Managed Applications. |
|
L3MAXFRAME |
Maximum number of frames sent
during a L3 Broadcast. |
|
L4TIMEOUT |
Timeout for L4 sessions (in
mSecs) |
|
L4WINDOW |
Maximum window to be used during
L4 sessions |
|
L3QUALAPP |
Default Quality assigned to
NETROM Managed Applications |
|
RTTMAX |
Maximum Network Horizon |
|
RTTINI |
Default RTT (msecs) |
|
RTTQUERY |
Interval for RTT meassurement
(in msecs) |
|
COMPRESS (YES|NOT) |
Enable generation of compressed
NETROM frames |
|
INP3 (YES|NOT) |
INP3 Compatibility mode (default
YES), see NETROM Improvements |
|
[NETROM.BLOCK] Section |
Optional, see NETROM Nodes Block |
|
[NETROM.APPLICATION]
Section |
Optional, see NET/ROM Managed Applications |
|
[HTTP] Section |
Optional, See HTTPd Server |
|
[CLI] Section |
|
|
[CLI.ALIAS] Section |
Optional, See Command Line Interface Aliases |
If
the DIGIPLEX.INI file can not be found the default values are used by
the program, however those defaults might or might be not appropriate to your
particular configuration. Since the file is a normal ASCII file it could be
edited with any text editor such as Windows’s Notepad or Edit.
Follows a sample of the DIGIPLEX.INI
which is being used for on-the-air tests of the program (included in the
distribution file).
[DIGIPLEX]
IP_ADDRESS=127.0.0.1
TCP_PORT=8000
DEBUG=YES
TRACE=1
CALLSIGN=LU7DID-1
LOGFILE=DIGIPLEX.LOG
RECOVER=NOT
NODEPASS=DIGIPLEX
[CLI]
ACTIVE=YES
TIMEOUT=1200000
PROMPT=DIGIPLEX:
BYE=GoodBye!
WELCOME=**
WELCOME TO ABROWN **
[BEACON]
ID=ID
TEXT==3448.00S/05823.90W-APRS
*145.15/431.20 LU7DID-1 (Adrogue,BA,Argentina) *
EVERY=240000
VERBOSE=NOT
[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
[ROUTER]
ENABLED=YES
NETROM=YES
PUBLISH=YES
MASTER=60000
LOADROUTE=YES
MHEARD=YES
ALIAS=DBROWN
ROUTES=ROUTES.INI
[NETROM]
L3QUALMIN=1
L3QUALDEF=200
L3OBSMIN=1
L3OBSMAX=60
L3QUALAPP=255
L3POLL=60
L4TIMEOUT=240000
L4WINDOW=2
L3MAXFRAME=999
RTTMAX=600000
RTTINI=60000
RTTQUERY=600000
COMPRESS=NOT
INP3=YES
[INTERFACE]
ax1=1,LU7DID-1,,240,SMART,APRS,ROUTER
ax2=2,LU7DID-7,,255,SMART,APRS,ROUTER
ax3=3,LU7DID-8,,100,SMART,APRS,ROUTER
lpb=4,LU7DID-9,,80,SMART,APRS,ROUTER
ip1=5,LU7DID-10,,240,SMART,APRS,ROUTER
[CLI.ALIAS]
BBS=C 4
LU7DID,LU7DID's BBS
DXC=C 4
LU7DID-3,DX Cluster
DOS=T
lu7did,Telnet to LU7DID Radio Box
XNET=C
4 LU7DID-4,(X)Net Router
TELNET=C
4 TNCLI,Telnet Manager
DXC=C 4
LU7DID-3,DX-Cluster
GATE=C
4 IW0DAM,Gateway PISAGW
PISAGW=C
4 IW0DAM,Gateway PISAGW
NQNGW=C
4 LU0YYN,Gateway NQNNOS
[NETROM.APPLICATION]
BBS=4,LU7DID,LUGATE
[HTTP]
ENABLED=YES
PORT=8009
SYSOP=Pedro
QTH=Adrogue,BA,Argentina [GF05TE]
The program uses the concept of a listener or
Interface or port, each port behaves as a different digipeater for all practical
purposes, so cross-activity is allowed between all ports for whom an interface
had been defined.
The overall format of the entries at the INTERFACE
section (one entry per listener) is as follows:
{Interface Name}={Port},{CALLSIGN-SSID},{ALIAS},{Quality},[Optional
Directives]
All interfaces verifies the traffic on all AGWPE
ports but only digipeats on the one it owns.
Please note the ALIAS is not longer functional for
any purpose (should be coded as two consecutive commas) while the CALLSIGN-SSID
differentiated by port is still needed but for digipeating functions NOT for
the NETROM router.
So a request to digipeat a frame on any port thru
any of the defined listeners will make that listener to perform the actual
digipeat of the frame over the port it owns, the frame is manipulated in order
to reflect it’s source as been the listener on the port it was heard enabling
the backward path to be used.
i.e.
The
[INTERFACE] 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
When the frame
2:
Fm: LU9DGN To: LU3DY via LU7DID-1 <SABM>
is
heard, it’s on the port owned by LU7DID-2 (port 2) but addressed to the listener
on port 1 (LU7DID-1) so it will be digipeated thru port 1 as follows:
1:
Fm: LU9DGN To: LU3DY via LU7DID-2* <SABM>
Please
note that the frame has been altered in order to reflect the path any answer to
it has to follow, actually, when the other end answers:
1:
Fm: LU3DY To: LU9DGN via LU7DID-2 <UA>
The
inverse process takes place and the frame is digipeated as:
2:
Fm: LU3DY To: LU9DGN via LU7DID-1* <UA>
Please
note that if the callsign-ssid of the listener matches the port it owns the
digipeater repeats the frame over the same channel, as in the following example
sequence:
2:
Fm: LU9DGN To: LU3DY via LU7DID-2
<SABM>
2:
Fm: LU9DGN To: LU3DY via LU7DID-2* <SABM>
2:
Fm: LU3DY To: LU9DGN via LU7DID-2 <UA>
2:
Fm: LU3DY To: LU9DGN via LU7DID-2* <UA>
Please note that each listener has to have a different CallSign-SSID assigned in order to define uniquely which is the exit port of the frames.
Aliases are used mostly by routing functions, if not informed the default stated in the ROUTER section of the DIGIPLEX.INI file will be used. The alias is not informed merely by stating two “,” together.
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.
digi1=1,LU7DID-1,ALIAS,100,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).
Please,
also note that even if the Routers had been disabled the Quality value still
needs to be informed; if you don’t use any router (in particular, if you don’t use
the NETROM router) put any numeric value there between 1 and 255 just to
satisfy the parsing of the Interface line.
For
further information on the functional aspects of the SMART mode see Smart Mode.
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.
ax1=1,LU7DID-1,ALIAS,150,ROUTER
Digiplex
saves periodically a snapshot of it’s routes (both Digiplex and NETROM) on the
ROUTES.INI file.
The
format of statements in the file are as follows:
SYS NETROM NODE ADD {port} {callsign-ssid} {alias} [LOCK}
SYS NETROM ROUTE ADD {destination} {alias} {port}
{callsign-ssid} {quality}
The content of the ROUTES.INI file is read back by Digiplex upon startup if the LOADROUTE directive is set to YES on the ROUTER section or when the SYS LOAD command is executed.
The
content of the file is refreshed every [ROUTER].MASTER milliseconds.
The DIGIPLEX program is intended to work over the traffic passing thru the AGWPE
and thus it has almost no provision to be used by the end user, upon execution
it will create a small icon on the Windows Tray Area.
The program will operate until it’s terminated by
means of right clicking on the tray area icon with the mouse and selecting shutdown.
The program requires the AGWPE program
to be up and running in order to operate because it relies on it to receive and
transmit AX.25 frames, if the communication with the AGWPE
program is interrupted during the course of the operation a retry mode will be
entered in order to regain that communication if the RECOVER parameter on the
DIGIPLEX section is set to YES, and will be terminated if set to NOT (default
and recommended setting).
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.
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:
[INTERFACE]
ax1=1,LU7DID-9,ABROWN,100
While a
listener entry supporting APRS
[LISTENER]
ax1=1,LU7DID-1,ABROWN,100,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 digiplex program implements two routing algorithms; the routing capability is in general enabled with the ENABLED clause on the ROUTER section of the DIGIPLEX.INI file, on top of that each router has to be specifically enabled.
If [ROUTER].ENABLED=NOT the SMART mode still could
be used but the node won’t attempt to neither collect nor route frames in any
way; in this situation the program could be seen as a simple “one-hop” router
that still could be used as a cross-port digipeater.
When
ENABLED=YES the program will behave depending on the configuration as:
The
modes will be seen with more detail on the incoming sections.
The DIGIPLEX program will announce itself to the network as a NET/ROM compliant node thru all interfaces where the clause “ROUTER” is indicated.
The
implementation will:
The implementation aims to achieve some NET/ROM
interoperability in order to interact with neighboor NET/ROM nodes and to get
some routing benefits for the digipeater (such as to tunnel thru a NET/ROM
cloud on the SMART digipeating mode) but it’s not aimed to provide a full
implementation of NET/ROM nor to become a NET/ROM router as it’s core
functionality. Full compatibility with all NET/ROM implementations is yet to be
tested; all tests done so far were done with G8BPQ and (X)Net neighboor nodes.
The
NETROM=YES clause on the ROUTER section enables the NETROM router.
Actual configuration of the NETROM router should follow the local LAN conventions and recommendations, please check with your neighboor sysops for guidance.
A
tipical configuration follows
[ROUTER]
....
NETROM=YES
LOADROUTE=YES
[NETROM]
…
L3POLL=60
L3OBSMIN=10
L3OBSMAX=60
L4TIMEOUT=240000
L4WINDOW=2
L4QUALAPP=250
L3QUALMIN=10
L3QUALDEF=200
....
This
configuration would keep the internal cycle of Digiplex at once per minute (MASTER). Routes would be saved on the
ROUTES.INI file at
each cycle
and loaded inmediately after restart (LOADROUTE=YES).
The NODES frame would be sent every 60 master cycles (L3POLL).
Inmediately after hearing a station a nominal Obsolesence value of
60
would be assigned and reduced at every master cycle until the
minumum
(L3OBSMIN) is reached; when that happens the route will be
removed.
Layer 4 Connections will last a maximum of 240 Secs (L4TIMEOUT) in
idle
state and frames would be sent 2 at a time (L4WINDOW).
The minimum quality to export a given route would be L3QUALMIN and
whenever necessary a default quality of L3QUALDEF will be used.
Digiplex allows to define applications to be broadcasted as NET/ROM nodes so other neighboor nodes could access them using a Layer 3 routing; typically such applications are BBS, DX-Cluster, Gateways, Conference Servers or other common infrastructure services.
The
application is assumed to:
·
Be
executed on the same node than the Digiplex node that publish them.
·
Be
accessible thru the loopback port.
In
order to define such applications the NETROM.APPLICATION section of the DIGIPLEX.INI
file must be configured.
Each
application will be configured with an entry using the following format:
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.
You
could manage the network horizon of managed applications thru the selection of
the quality assigned to each port (thru the Listener definition) and the
minimum quality to export (L3QUALMIN).
In
certain network scenarios a node could be heard but not contacted to establish
a link (either under INP3 or normal NETROM).
In
such scenario attempts to connect will be performed from time to time and even
if the route wouldn’t be established as good the continuous attempt to
establish a doomed link might create unnecesary interferences and channel load.
When
such situation exists nodes that will be blocked for any attempt of direct
contact might be defined including them on the [NETROM.BLOCK] section of the
DIGIPLEX.INI file as follows:
[NETROM.BLOCK]
{nodealias}={port},{nodecall}
As many entries as needed could be informed.
Basically,
the entries forces Digiplex not to take any broadcast from the indicated nodes
as well as do not include them on any Digiplex routes broadcast; nodes listed
would be prevented to be considered as direct neighboors but they could still
be accessed if reported by a non-blocked neighboor on it’s own routes.
Digiplex does not implements INP3 as a routing algorithm, however it address compatibility issues thru the following functions:
Even if Digiplex isn’t a NETROM/INP3 compliant router it does implements some concepts from INP3 to improve the overall performance and routing capabilities.
It
does so in a way that remains compatible with both “old NETROM” (i.e. BPQ) or
new INP3 routers (i.e. XNet).
The
enhancements are:
This
behaviour could be turned off with the directive [NETROM].INP3=NOT, in that
case Digiplex will route strictly based on the best quality to a given
destination based on the combination of the Quality of each port (as assigned
by the sysop on the [INTERFACE] section) and the Quality reported by each
neighboor to a given destination.
The
Digiplex origin of frames is marked thru a RIF formatted fields using the $Z
marker (pretty much in the same way than INP3 routers marks themselves using
the $N marker) so Digiplex routers could be made aware of which of it’s
neighboors are also Digiplex.
When
that situation is detected and the [NETROM].COMPRESS configuration directive is
set to YES the exchange of frames is made using compression (LZRW1/KH
algorithm) in order to save bandwidth. Compressed frames are carried using the
PID 0xCA in order not to conflict with other non-Digiplex NETROM routers in the
area.
The
NETROM protocol is fully used, only that the Layer 2 info section of the frame
is compressed (if compression makes sense for a particular frame).
Frames
where compression doesn’t yield any benefit are transmitted using the regular
NETROM PID 0xCF; both kind of frames could then appear on any given connection on
any order depending on the actual data being carried.
Compression
usually achieves an average of 20-30% reduction of the gross volume transferred
creating bandwidth savings.
If the NETROM router is enabled the information gathered by the node (as a NETROM router) will be under certain circumstances used to optimize connections which aren’t NETROM (ie. regular AX.25 connections).
If
a frame which has one of the CALLSIGN-SSID of the node interfaces as part of
the path is heard and then the SMART hop-2-hop mechanism is activated (if
enabled) the destination is inspected to see if it’s a known NETROM resource.
If
it is; instead of trying to connect it directly the NETROM node that should be
used to route NETROM frames for it is connected instead (based on the best
quality path); once that connection (which is performed like a end user) is
established then a “C Destination”
is
transmitted to the NETROM node in order to trigger the transport of the frame
thru the NETROM network tunneling thru it.
When all routing attempts fails using NETROM another router might step into action if enabled with the MHEARD=YES directive in the ROUTER section.
It’s
a simple guess-routing appropriate for one hop connections where the
destination is contacted directly (using a simple L2 connection, it doesn’t
require to be a node itself) thru the last port it was heard.
Chances
are that the station was upon a time heard and kept by AGWPE on the Mheard list
but no longer available; obviously this routing will succeed if the station is
available and the node is able to establish a connection with it.
The
MHEARD router works at two different moments:
Digiplex includes a simple Web Server that could be used to gather status information about the node thru simple commands, this Web Server (HTTPd server) is completely optional and it’s not involved on any actual operation of the node.
·
Configure
the HTTP section of DIGIPLEX.INI
[HTTP]
ENABLED=YES
PORT=8009
QTH=QTH Information
SYSOP=Sysop Name and/or CallSign
Change the
PORT value to any suitable value for your installation, if you have already a Web Server running probably
port 80 is already hooked up by it. Try
Port 8009. Beware NOT to use any port currently in use, specially the ports allocated by AGWPE
(8000,...). Use the netstat –a
command in case of doubt.
You could
customize all command related pages changing
the TEMPLATE.HTM file to fit the overall “look & feel”
of the Web site where the pages would be presented.
The
server isn’t intended to provide content by itself but just to be integrated
with another (existing) Web Server and to
provide the content related to the node operation.
The
logic of the server to provide content will be:
·
If
the required resource has an extension different from “HTM” it will be served
as a binary file.
o
A.HTM
AX.25 Parameters.
·
All
the internally produced pages will use the file TEMPLATE.HTM as the mask to
produce the content. The meta-tag “<#DATA>” will receive the specific
content of the command being executed internally.
·
The
metatags <#QTH>, <#SYSOP> and <#ALIAS> will be replaced by
the respective configuration parameters.
The
HTTPd server does not execute third party programs (CGI or others) other than
the supplied set for security reasons.
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.
Current
commands not necessarily will survive to the late stages of development, it
could be protected or even could be removed as development progress.
To
access the CLI you might connect to the Callsign-SSID stated on the CALLSIGN
configuration parameter (DIGIPLEX section) thru any of the ports for which a
listener had been configured.
Upon
connection the program will basically wait for the first user input, this might
be rather confusing, but it’s necessary to understand whether it’s a “normal”
user or another node willing to start an internode connection.
Upon
the first command (or even the first CR) sent a banner will be displayed, this
is that way to ensure the proper PID of the connection (user or internode) is
sensed before the first frame is sent.
Then
the list of available functions could be obtained with the “?” or “h” commands.
The
(probably) most useful commands will be:
No
command issued could create any real harm (except, perhaps, the SYS command),
but of course, an improper sequence of commands might lead to the improper
function of the node, beside the above commands all others should be exercised
with caution and an overall experimental mood.
Most
of the commands results would be self explanatory with the probably exception
of the “n *” command; the format and meaning of the result will be:
P(n)XN(ALIAS:CALLSIGN) St(XXX) RTT(nnn) Q(mmm)
[DPX|LOCAL|LOCK|IN3] D(hh:mm:ss)
N(ALIAS:CALLSIGN) O(nn) Q(nnn)
The first line reflect a neighboor node heard thru “P” port, with a Status (St) that could be
· CONN Connected
· DISC Disconnected
· TRY! Connection being attempted
· CUT! Disconnection in progress
The “X” value could be
· > This is the present preferred route to this destination.
· ? This destination seems to have no valid routes.
· Blank This is not the preferred route for this destination.
When connected the RTT meassure the turnaround time in milliseconds, Q the quality applied to this particular neighboor, special conditions of that neighboor such as:
· LOCK Locked Route
· LOC Local Application
· IN3 NETROM/INP3 Neighboor
· DPX Digiplex Neighboor
And finally the timestamp of the last broadcast heard from that neighboor.
The second line format refers to routes thru the neighboor. Q reflects the compound quality to that node (Quality to neighboor factored to Quality between the neighboor and that destination) and O reflects the Obsolecense counter for that particular entry.
Destinations thru nodes currently not connected aren’t shown, if any, will be presented again when the neighboor node could be contacted.
The
configuration of the Command Line Interface is made thru the entries at the CLI
section of the DIGIPLEX.INI file or thru the Properties GUI
Relevant
entries are:
·
ACTIVE
(default YES), enables the Command Line Interface; the CLI could only be
disabled if the program is used as a Cross-Port digipeater..
·
TIMEOUT (default 60000, 1 Min),
this is the amount of inactive time a connection could have before to be
terminated automatically.
·
WELCOME, Welcome String to be sent to the user upon connection (both AX.25 and
Telnet).
·
ERRORMAX (default 3), is the maximum number of consecutive command errors a
session will be tolerated to have before been disconnected.
Once enabled the Telnet Client will export the CALLSIGN:ALIAS as a managed application for other neighboor NETROM nodes to establish routes to it.
All
commands accessible thru the CLI have a “security level” associated with it; security
levels could range from 00 (minimum) to 255 (Maximum).
Each
user connected to the node is associated with a “security level” too, so that
particular user could execute commands whose security level is lower or equal
than his/her own security level.
AX.25
user have a security level of $08 and Web users have a default security level
of $00; this is not configurable.
All
informational commands have a security level of $00 associated. All node
commands have a security level of $FF.
In
order to achieve the security level required to execute the SYS command ($FF) a
LOGIN command must be issued.
The
node will react with a 5 number (random) sequence which will reflect positions
on the node password ([DIGIPLEX].NODEPASS); the characters on that positions
must be supplied in order for the node to enter a “sysop authorization” mode
where the SYS command is enabled; the password validation is case sensitive.
If
not configured the default NODEPASS value is “DIGIPLEX”.
When a connection is made (AX.25) the file WELCOME.INF will be sent to the user if exists as a banner (or splash file); the content of the file could be customized by the operator of the node to provide short messages and suitable operational information.
If specialised messages are required for each port files named as Cx.INF could be configured (being x=port); if a file with this naming convention is found it will be sent instead of the WELCOME.INF file.
If
the file is not found a default banner is sent to the user as set on the
[CLI].WELCOME configuration entry of DIGIPLEX.INI
The
following files could be configured by the sysop and shown to the users instead
of the default messages.
MOTD.INF Message of the Day, sent inmediately after
the WELCOME.INF file if present.
Mx.INF With x=port will be sent
instead of MOTD.INF if present when a connection is made on that port.
HELP.INF Help file to be shown then the ? or h
command is executed at the CLI.
Follows the reference of the commands available at the node.
This
command list the AX.25 parameters of a given interface as configured in AGWPE,
general format is:
A {interface}
Result:
AX.25 Parameters for Port
Parameters for Port (nnn) Port n with XXXXXXXXX
OnAirBaud
(xxx)
Traffic Level
(xxx)
TXDelay
(xxx)
TxTail
(xxx)
Persist
(xxx)
SlotTime
(xxx)
MaxFrame
(xxx)
AX25Channel
(xxx)
HowManyBytes
(xxx)
Please
refer to the AGWPE documentation for the meaning of each configuration
parameter.
Layer
2 configuration paremeters could not be changed from Digiplex,
appropriate changes must be done using AGWPE facilities.
This
command list the configured ports as defined in AGWPE, general format is:
P
Result:
Ports:
Int(xxx) Type(AX.25) Port(n) XXXXX—(Description)--
Where
Int Is
the interface nickname as configured in the [INTERFACE] section.
Type AX.25
Port Port
number as defined in AGWPE
Layer
2 configuration paremeters could not be changed from Digiplex,
appropriate changes must be done using AGWPE facilities.
This
command list the stations heard on a given interface as reported by AGWPE,
general format is:
J {interface} or
MH {interface)
Result:
Heard List for Interface(xxx)
Stations Heard on Port (xxx) XXXXXXXXXXXXXXXX
AAAAA Mar,03Abr2001 11:37:26 Mar,03Abr2001 13:12:37
All
heard stations in the port are listed with the indication of the first time and
the last time the station was heard.
This report is produced with information as provided by AGWPE, including the order or the entries.
The command list all Nodes known to the NETROM router, the argument will define the format of the list:
A
simple list with a summary of all nodes known to the router will be produced
such
as:
Nodes:
LU7DID:LUGATE LU7DID-4:ABROWN GB7CGL:WOOLDX
IW0DAM:PISAGW LU0YYN:NQNGW LU7DID-3:DXCDID
N1OTX:BROCK TNCLI:TELMGR G0CGL:DXCCGL
LU3DY:RCBURZ LU3DY-4:3DYNOD LU6DK:BBS6DK
LW4DBE:DBEBBS LU3ERX-4:LANUS LU6DK-4:RCLDZ
LU9DGN-1:TMPY LW4DBE-4:DBENOD LU4DQ-4:R.C.Q
LW1DTJ-4:SUR LU4DO:DO LU4DO-4:AVELLA
LU9DGN:MIKE
Nodes
list will be produced ordered alphabetically by Alias name.
A comprehensive list of all neighboor nodes and
routes will be produced, such as
NETROM Routes:
P(4)>N(LUGATE:LU7DID)
St(-*-) Q(255) LOC D(11:37:16 a.m.)
P(4)>N(ABROWN:LU7DID-4)
St(CONN) Q(71) IN3 D(01:48:18 p.m.)
>N(WOOLDX:GB7CGL)
O(52) Q(67)
>N(PISAGW:IW0DAM) O(52) Q(67)
>N(NQNGW:LU0YYN) O(52) Q(67)
N(LUGATE:LU7DID) O(52) Q(67)
>N(DXCDID:LU7DID-3) O(52) Q(67)
>N(BROCK:N1OTX)
O(52) Q(67)
>N(TELMGR:TNCLI) O(52) Q(67)
>N(DXCCGL:G0CGL) O(52) Q(67)
N(RCBURZ:LU3DY) O(51) Q(64)
N(3DYNOD:LU3DY-4) O(51) Q(66)
N(BBS6DK:LU6DK) O(51) Q(17)
N(DBEBBS:LW4DBE) O(51) Q(17)
N(LANUS:LU3ERX-4) O(50) Q(43)
N(RCLDZ:LU6DK-4) O(50) Q(48)
N(TMPY:LU9DGN-1) O(60) Q(43)
N(DBENOD:LW4DBE-4) O(50) Q(48)
P(1)>N(RCLDZ:LU6DK-4)
St(DISC) Q(215) D(01:40:48 p.m.)
>N(BBS6DK:LU6DK)
O(53) Q(83)
N(DBENOD:LW4DBE-4) O(53) Q(7)
N(3DYNOD:LU3DY-4) O(53) Q(7)
N(RCBURZ:LU3DY) O(53) Q(7)
N(LANUS:LU3ERX-4) O(53) Q(5)
N(TMPY:LU9DGN-1) O(53) Q(5)
P(1)>N(DBENOD:LW4DBE-4)
St(DISC) Q(215) D(01:34:52 p.m.)
>N(DBEBBS:LW4DBE)
O(47) Q(83)
N(RCLDZ:LU6DK-4) O(32) Q(8)
>N(R.C.Q:LU4DQ-4) O(47) Q(8)
>N(SUR:LW1DTJ-4) O(47) Q(8)
N(3DYNOD:LU3DY-4) O(47) Q(8)
N(RCBURZ:LU3DY) O(47) Q(8)
P(2)>N(LANUS:LU3ERX-4)
St(DISC) Q(229) D(01:40:51 p.m.)
>N(DO:LU4DO)
O(22) Q(182)
>N(AVELLA:LU4DO-4) O(22) Q(186)
>N(MIKE:LU9DGN) O(22) Q(210)
>N(TMPY:LU9DGN-1) O(22) Q(210)
P(1)>N(3DYNOD:LU3DY-4)
St(DISC) Q(215) D(01:28:57 p.m.)
>N(RCBURZ:LU3DY)
O(41) Q(209)
N(BBS6DK:LU6DK) O(41) Q(62)
N(RCLDZ:LU6DK-4) O(41) Q(161)
N(DBENOD:LW4DBE-4) O(41) Q(161)
N(DBEBBS:LW4DBE) O(41) Q(62)
Lines
starting with a “P” (port) refers to neighboor nodes directly heard, the Alias,
Callsign-SSID, current status, Quality and last time heard is listed.
Also
the qualifiers LOC, IN3, DPX and LOCK might appear showing that neighboor is a
Local (managed application), INP3, Digiplex or a Locked route.
If
the INP3 compatibility mode is enabled the current RTT to that neighboor is
shown, the Obsolesence is listed otherwise).
Dependent
nodes (nodes routed thru a neighboor) are listed following the neighboor entry.
For
each route the current obsolesence and the compound quality of the route is
shown.
Entries
listed with a “>” means currently selected as best route, “?” means invalid
as a route.
This command will have a content similar to N * but only listing entries related to the neighboor “Callsign-SSID”.
The Route command list the possible routes for a given destination, it list both the “would be result” of the NETROM and MHEARD routers.
R CALLSIGN-SSID or R ALIAS
will produce as a
result
NETROM Route:
Call(CALLSIGN-SSID) ŕ (Port:Node)
MHEARD:
Call(CALLSIGN-SSID) Route(Port:CALLSIGN-SSID)
NO
ROUTE will be shown instead of a route if none could be found.
This
command has no effect on the actual routes, it’s merely for information purposes,
to set or remove routes the SYS command must be used.
Display the on-going L2/L3/L4 links active at the node:
L3 NETROM Connections:
Node(4:LU7DID-4)
St(CONN)
Node(1:LU6DK-4)
St(DISC)
Node(1:LW4DBE-4)
St(DISC)
Node(2:LU3ERX-4)
St(DISC)
Node(1:LU3DY-4)
St(DISC)
L2 Digipeater Connections:
Id(8) St(CONN)
(2:LU9DGN)--[D00008-15:LU9DGN-14]
L2 Digipeater Connections refers to virtual circuits held by the cross-digipeater function when the smart mode is active. The originator of the circuit, the internal callsign-ssid used and the final destination are listed.
Display the on-going L2/L3/L4 links active at the node:
L2 Connections:
Port(4)
LU7DID<->LU7DID-1 Auth(8) St(0)
Port(4) LU7DID-4<->LU7DID-1
Auth(8) St(0)
Port(4)
LU7DID-13<->LU7DID-1 Auth(8) St(0)
Port(4)
LU7DID-12<->LU7DID-1 Auth(8) St(0)
Port(4)
LU7DID-5<->LU7DID-1 Auth(8) St(0)
L2 Digipeater
Connections:
Id(9) St(4)
(2:LU9DGN)--[D00009-15:LU9DGN-15]--(1:LU6DK)
Id(10) St(0) (2:LU9DGN)--[D00010-15:LU9DGN-14]--(1:LU3DY)
NETROM L4
Connections:
(LU7DID-4<->LU7DID-1)
Loc(1:9) Rem(8:37) Window(2) St(2)
L2 Digipeater Connections refers to virtual circuits held by the cross-digipeater function when the smart mode is active. The originator of the circuit, the internal callsign-ssid used and the final destination are listed.
The connect command could be used by stations logged on the node and will produce different results based on the destination and the current configuration of the node.
The
general format is:
C {port} CALLSIGN-SSID {via Call1 Call2)
If the port is omitted the destination (CALLSIGN-SSID) will be handled as a NETROM node and the proper route to it will be defined based on routing information, if a valid route could be found a L3/L4 connection will be started.
If
no NETROM route could be found a best can do routing attempt will be made by
the MHEARD router if enabled; the MHEARD router could only route if the station
was heard thru a single port, if a given target station was heard thru more
than one port the MHEARD router will not try to route the connect. Connections
started by the MHEARD router are Layer 2 AX.25 connections even if the
destination is a NETROM node.
Other
(generic) destinations could be connected but the port information must be
provided. Digiplex doesn’t alter the port information when provided, also Layer
2 AX.25 connections are attempted when the port information is provided
disregarding the actual nature of the target (node or not node).
When
port information is provided the node behaves as a gateway.
This command display the current software
level of the node
Version 0.72 Build(22)
This command a timestamp of the current clock
of the node for verification purposes
Date/Time:
03/04/01 01:20:36 p.m.
The
command list an informational picture of the status of the node when executed
without arguments:
DigiPlex Version 0.72 Build(22) Pedro E. Colla
(LU7DID) 2000,2001
Digipeater Node(LU7DID-1)
Up since: 03/04/01 11:37:15 a.m.
L2 Connections
Port(4) Call(LU7DID)
Port(4) Call(LU7DID-4)
Port(4) Call(LU7DID-15)
Defined Interface(s)
Name(AX1) Type(AX.25) Port(1) Call(LU7DID-1)
APRS(YES)
Smart(YES) Router(YES
Name(AX2) Type(AX.25) Port(2) Call(LU7DID-7)
APRS(YES)
Smart(YES) Router(YES
Name(AX3) Type(AX.25) Port(3) Call(LU7DID-8)
APRS(YES)
Smart(YES) Router(YES
Name(LPB) Type(AX.25) Port(4) Call(LU7DID-9)
APRS(YES)
Smart(YES) Router(YES
L2 Connections 3
L2 Digipeater Connections 0
MHeard Router: TRUE
NET/ROM: TRUE
Alias: DBROWN
Clock: 60000 mSecs
Nodes: 22
Circuits:1
Router
Parameters
-- L3 --
Obs
(Ini):60
Obs
(Min):1
Qual(Def):200
Qual(Min):1
Qual(App):255
Broadcast:60 Mins
Compress
:TRUE
Publish :TRUE
RTT (Ini):60000 mSecs
RTT
(Max):600000 mSecs
Query
RTT:1200000 mSecs
-- L4 --
L4
Window:2
L4
TOut :240000 mSecs
When
the command I (Information) is executed with arguments a file could be defined
by the operator to be sent instead of the default content of the command.
Information
associated must be configured on a file named as {Arg}.INF.
I.E.
If
the user types
I
HARDWARE
The
content of the file HARDWARE.INF will be sent if the file exists.
All node management commands have been grouped into
the SYS command; this command will operate with sub-arguments as follows:
SYS NETROM ?
SYS NETROM SET ParmName {Value}
* ParmName is the same
name of parameter
in DIGIPLEX.INI
SYS NETROM BROADCAST (Forces a NETROM
Broadcast)
SYS NETROM COMPRESS {ON|OFF}
SYS NETROM NODE {ADD|DEL} {port}
{callsign} {alias} LOCK|LOCAL
SYS NETROM ROUTE ADD|DEL {dest}
{alias} {port}{callsign} {Qty}
SYS INTERFACE {Interface} QUALITY nnn 1..255
SYS INTERFACE {Interface} APRS
{ON|OFF}
SYS INTERFACE {Interface} ROUTER
{ON|OFF}
SYS INTERFACE {Interface} TCP
{ON|OFF}
SYS INTERFACE {Interface} SMART
{ON|OFF}
SYS BEACON ?
SYS BEACON EVERY {value}
SYS BEACON TEXT {beacon_text}
SYS BEACON ID {beacon_id}
SYS BEACON BROADCAST
SYS MHEARD ?
SYS MHEARD {ON|OFF} {Only allowed if previosly defined}
SYS SMART ?
SYS SMART RESET Pid
SYS KERNEL TRACE {n}
SYS KERNEL INFO
SYS SHUTDOWN (Requires auth level of 255 to execute)
The
SYS command requires an authorization level of $FF to be executed, regular
AX.25 connections carries an authorization level of $08.
In
order for the SYS command to be authorized the LOGIN command must
be used first.
Upon
execution the user is challenged with 5 random position of a passphrase such as
System
Key ŕ[ 3 4 1 2 1 ]
The
correct letters (case sensitive) must be provided for those positions in order
for the access to be cleared.
If
the access is validated an “Ok” is produced and the prompt presented, if the
access is not validated only the prompt will be presented.
The
password or passphrase itself is configured on [DIGIPLEX].NODEPASS and if not
configured is set as “DIGIPLEX” by default.
Aliases could be established for commonly used commands thru the CLI.ALIAS section of the DIGIPLEX.INI file or equivalent GUI facility.
The
entries will follow the following sintax:
ALIAS=Command
to be Executed,Description
All
Aliased commands have a security setting of $00 (enabled to all users).
A couple of paragraphs related to FlexNet compatibility.
Up to level 0.70 some attempt to provide FlexNet interoperability had been done; given the absolute mistery on the FlexNet internode protocol and the availability of FlexNet compatible node software for the AGW Packet Engine platform all FlexNet compatibility functions had been removed.
There is no current plan to support any FlexNet related function in the future other than the interoperability as a digipeater.
In
case the program doesn’t work as expected several reasons might happen for
that, the most common situations are:
In
general, in case of difficulty it might be helpful to activate the logging of
the program (DEBUG=YES) and slowly increase (on sucessive tries) the level
of tracing (TRACE={1ŕ5).
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.
When
the AR DX Cluster is defined as a “NETROM Managed Application” users could not
get into the cluster thru NETROM routes.
This is because AR DX Cluster has a bug with SSID=15, the author doesn’t answer mails related to the problem.
A
workaround is to define DXCLUSTER=YES on the DIGIPLEX section of DIGIPLEX.INI,
this will force Digiplex to restrict the usage of SSIDs into the range 0 to 14.
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 (watch for the word “Exception”).
AGW
Packet Engine Version 2001.10+ must be used.
If
already using it run DIGIPLEX with DEBUG=YES, TRACE=1 and inspect on the
DIGIPLEX.LOG for problems during the initialization.
Currently, the Digiplex program implements several concepts in one; some of them are closely related while others are relatively independent. Unfortunately the user interface is still very primitive and relatively hard for the user to configure the different modes.
Those concepts are the SMART mode, the NETROM
routing and the MHEARD routing.
It is worth to clarify the role of each one.
The SMART mode is enabled at
the Listener level by means of the “SMART” directive, it deals only with the
operation of the digipeater as “dumb” or “smart”; in other words, it controls
whether or not a straight frame digipeating (dumb) or a “hop to hop ack” is
performed. This mode could be used independent of all the others, even if no
router at all is enabled this mode could be operated.
The NETROM mode is enabled
by three configuration actions. Each listener has to be enabled for routing
thru the usage of the ROUTER directive, the ENABLED configuration has to be set
to YES and the NETROM configuration has to be set to YES also. When those
conditions are met that particular listener will be sensitive to broadcasted
NETROM routes (UI frames directed to NODES), will route NETROM L3 frames and
could sustain connections from other nodes either to the listener itself (to
access the Command Line Interface) or to any managed application. It will also
broadcast it’s own routes periodically thru an UI frame directed to NODES. This
mode could co-exist with the same listener operating as a DIGIPLEX node (albeit
it’s not recommended at this stage of development). This mode is optional too,
if you don’t want (need) a NETROM node, you could just not configure it.
The MHEARD mode is enabled
by three configuration actions. Each listener has to be enabled for routing
thru the usage of the ROUTER directive (same as NETROM), the ENABLED
configuration has to be set to YES (same as NETROM).
When a listener on a node is
enabled for the MHEARD mode connections attempts from a “connected” user with
no port information will be attempted to be resolved looking for the
destination on the AGWPE heard list.
If the destination could be
found (univocally) in one port (not counting the loopback port) the connection
will be triggered using that port; if not found or found on more than one port
an error will be returned.
Infrastructure resources are usually perceived as high reliability, boxed and single purpose devices that sits unattended on a mountain top or other isolated place; this is actually the case in most situations.
On that scenario the “perceived” stability of an
Intel box running some variant of Windows as required by AGWPE doesn’t seems to
fit as a solution.
Probably a PC running anything might not be a good
solution for a mountain top in any case, just out of energy considerations; a
dedicated and relatively simple box could do a great job on that role.
Still, to run a Wintel box on an unattended place is
not as far fetched as it might sound, specially if WinNT or Win2000 are used;
those operating system had almost none of the classical “unstabilities” of
their small version cousins of the Win9x/ME kind, and are actually quite robust
if carefully installed and maintained. Actually, many mission critical IT
applications with extremely high availability are executed on such platform.
But Digiplex had been designed more as a routing
complex for a power station on a given zone than as a “range extender”
resource.
It’s main features are the cross-port capabilities
(capability to link LANs from a common station with mutual accesibility), and
classical on-the-LAN routing functions (NETROM and MHEARD); probably this order
of importance is a fair statement in itself.
As such, the resources needed to achieve the purpose
of the program would probably not be found at isolated or unattended places but
at the very heart of a power station on a given area.
In the short term, and while the program is under
development it doesn’t have the stability needed for a non-supervised
operation; but if the development continues enough for it to achieve some level
of maturity that scenario won’t be completely unthinkable.
A word about IP Addresses
If your machine is not connected to a LAN and have assigned a
permanent address it is likely that even if your TCP/IP stack is configured you
don’t have a concrete IP ADDRESS to set this program. In that case you should
use what is known as the “loopback” IP Address, which is a
special IP Address that the TCP/IP stack in your machine uses to communicate
with itself. This loopback IP ADDRESS is usually either 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.
·
After
a while with AGWPE not available the program traps.
·
Ocasionally
during a “hop-to-hop ack” interchange frames are retained on an intermediate
node; the whole connection stops and eventually times out; the condition is
cleared when any end of the connection sends something (this is probably an
AGWPE problem but work is still being done on the subject).
Many people contributed with this program on its
different development stages, I could not account for all of those that thru conversations
(real, air or E-Mail) contributed to create in my mind the original idea.
The development itself wouldn’t be possible at all
without George Rossopoulos (SV2AGW) providing the AGW Packet Engine (AGWPE)
in the first place, extending the capability to interact with it thru TCP/IP as
opposed to the somewhat arcane DDEML original interface the program had and
lately reacting very promptly to make modifications and enhancements to AGWPE
during the development and test stages.
During the test of the program (an ongoing process)
I disturbed the patience of almost every sysop of my local LAN routing thru the
local nodes the most exotic digipeater connection paths anyone could think and
quite a few of corrupted or otherwise misbehaved AX.25 frames till I got things
reasonably right; in particular Juan E. Sanchez (LU9DGN) suffered the program
in very unstable and buggy conditions on his own node to allow me to have a
peer to work out many of the internals of the program.
Most of the detailed tests performed involving
remote TCP/IP connections involved the very important contribution of Paul
Anderson (N1OTX) which tirelessy implemented configuration change after
configuration change to allow me to evaluate (and correct) many aspects of that
mode.
The fix that makes possible the work of the AR DX
Cluster together with Digiplex could not have been possible without Eric
Carling (G0CGL) “nightmare” on the solution; Eric was instrumental on the
extensive (also exhaustive and somewhat boring) testing required to make the
NETROM router to properly work and interact with other implementations.
Useful suggestions related to the APRS functions
made by Olivier (F5PYF) and NETROM issues pointed by Christian (F5IX) lead for
a consolidation of both functions.
Many other people contributed with suggestions, test
reports and comments to be listed here, I could not move this program forward
without their involvement.
Please note that a L2 Digipeater program
(AGWDigi.EXE) written by George Rossopoulos (SV2AGW) is available and supported
by the author; whenever a L2 digipeater that operates over a single port is
needed the usage of that program is recommended.
I look forward for other people to actually use the
program and provide positive or critic feedback of it just drop me a note with
any special requirement or problem you might have.
I’m particularly interested on receiving benchmark
information about throughput of the program under different scenarios.
Initial release. Basic functionality.
Distributed for initial evaluation.
SMART mode introduced, performance optimizations on the digipeater. Additional parameters introduced. Beacon reformulated.
Modification in the
DIGIPLEX.INI format, multiple digipeater listeners allowed.
Added extended Beacon information (VERBOSE).
Added controls to avoid conflicting Listeners at the
DIGIPLEX.INI configuration.
Added possibility to route
beacon frames thru a digipeater path (please note that the digipeater will not
digipeat it’s own beacon frames).
Added support for APR.
Added support for the L2 Worm Digipeater Protocol (Digipeat over TCP/IP).
Changed the Smart algorithm.
Added support for the “Drunk” hop to hop ack mode.
Several performance improvements.
Countless bugs removed.
Renamed into Digiplex Version 0.5 Beta
Clean up of the program.
Performance optimizations.
Bug solutions on the SMART mode
(garbage I frames if connection drop In one end).
Pseudo L3 Layer (Router implemented).
Pseudo L3 Layer improved.
L2 Worm mode rewritten to
avoid a dedicated TCP/IP client and server to be used. The AGWPE at the other
end is directly connected instead of an intermediate Client/Server socket to be
used.
Initial working
implementation of the NET/ROM node.
Managed Applications concept
implemented.
Countless bugs removed.
Unknown number of bugs
introduced.
Modifications to the initial
working implementation of the NET/ROM node.
Countless bugs removed.
Unknown number of bugs
introduced.
The routers (both DIGIPLEX
and NET/ROM) has to be used strictly on experimental grounds.
Modifications to the initial
working implementation of the NET/ROM node.
Major modifications on the
NETROM implementation, specially the routing.
Option to make general or local
broadcasts of routes.
Fixed ROUTE command on CLI.
Applications are shown on
the command N of the CLI.
Initial GUI interface.
Initial Web interface.
Telnet Server added.
Splash screen upon start
added.
Could be used as a gateway
now (C command on CLI).
Optionally load routes on
start, file format different from previous versions.
Exception on UpdateNODES
fixed.
Exception on FindNR3Route
fixed.
Enhanced AX.25 timeout.
The usual crop of minor bugs
fixed, too many to document.
Who knows what other “feature”
added in the process.
Enhancements on the connection logic.
Update of the GUI.
Fix of the compatibility issue with AR DX Cluster.
Changes on the APRS WIDEN-N and TRACEN-N logic, it does cross-band now.
Many other small bugs fixes and enhancements.
Command Alias for CLI and Telnet access.
Integration between L2 Worm Router and NETROM increased (not
completed).
See README.1ST file for release specific information.
Web Server enhancements.
PING command.
Telnet out command on CLI.
Command structure reorganization, command security.
NETROM Alias recognition.
Optional Recover from AGWPE failures.
Digiplex will not start a second instance of itself on the same
machine.
Prompt fixed and interruption of commands.
TELNET.ALIAS consolidated into CLI.ALIAS
See the README.TXT file of this distribution to see changes made.
See the README.TXT file of this distribution to see changes made.
See the README.TXT file of this distribution to see changes made.
DIGIPLEX is free for radioamateur
and experimental uses, commercial use requires written permission from the
author. The author bears no liability for damages related to the usage of this
program nor guarantees the proper functional behaviour. I could certainly be
more sophisticated in legal terms, but in a nutshell use it at your own risk.
Publicly available information has been used to
understand the requirements, specially the AGWPE TCPIP Interface (AGWSockInterface.DOC
by G.Rossopoulos SV2AGW) and the “AX.25 Amateur Packet Radio Link Layer
Protocol” (AX25.DOC), all code used to implement this program comes from my own
development.
I’ve used the UIView32 Version 1.3 by Roger Baker
G4IDE documentation as a reference to the main features to be implemented in
order to support APRS (or UIView if you prefer), don’t really think I’m
violating the program license in any way I could see doing that. Please note
that UIView32 has a very good digipeater implementation on their own and it
does support AGWPE too, so users interested on a “full APRS” operation should
get it anyway.
The scheme to interoperate with FlexNet nodes is
strongly based on the work of IZ5AWZ (author of the AWZNode Linux program)
which in turn had been strongly influenced by the work of PE1RJA and OH2BNS.
If you need support, have suggestions, encountered
some bug or just are willing to provide feedback drop me a note at:
AX.25: LU7DID@LU7DID.#ADR.BA.ARG.SOAM
Inet: [email protected]