Previous- Index- Web- next- page
The DIGI_NED configuration examples.The DIGI_NED user manual, configuration examples, Version: 1.02-032 Date: January 14, 2002 By: PE1MEW (pe1mew@qsl.net).
About this manual
Preamble.
This is the DIGI_NED owner manual. This manual is intended to be the reference for APRS users using the near-by DIGI_NED digipeater and for DIGI_NED digipeater owners who wish to build and maintain their DIGI_NED APRS digipeater.
Contens of this MANUAL.
This Manual is separated in to different parts:
Manual availability and version number.
This manual uses the available documentation released with the DIGI_NED executeable and source distribution. In the top part of each page you can find the version number and release date.
Disclaimer.
This manual is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Comments and contributions.
If you have any additional comments or corrections to this documentation feel free to contribute.
To verify and add your contibution stick to these little rules:
Send your comments to the DIGI_NED team: digi_ned@qsl.net
The DIGI_NED configuration examples
Introduction.
The files applied to this document are example files and can be used with minor changes. The files contain full comments so they should inform you fully. If you have more questions see the DIGI_NED syntaxes.
To keep changes minor the choice was made to keep the files as original as they were. To use the files in a html environment the .txt extention was added. To use the files as configuration files simply take the .txt extention away and copy them to the required directory.
Using DIGI_NED as a generic digipeater.
This file "d_gener.ini" makes a generig digipeater using DIGI_NED. The big advantage of this generic digipeater compared to a TNC is that this digi is checking for duplicates !
This configuration contains:
Using the DIGI_NED default configuration.
This is the default "digi_ned.ini" file which comes with the distribution. I contains all basic functions for a normal intelligent APRS digipeater and more. Also all features that DIGI_NED contains are mentioned. Some of them are commented out as primary there is no need to activate it.
The DIGI_NED default configuration contains:
Commented out but described:
Using DIGI_NED for traffic reduction.
As DIGI_NED is capeable of manipulating a digi-path DIGI_NED is a powerful solution to run in a high-load traffic area. Using the powerfull rules a too long or unuseable digi-path can be corrected or reduced in time to live or hops.
This maunual contains a drop-in example for using in this environment. The "d_hiload.ini" file can be used to reduce the traffic on the APRS QRG a lot and.
The changes to the DIGI_NED default configuration:
This configuration will save a lot of traffic. Just take a look on what is have changed.
The function TRACEn-N is now useless but in a developed network not needed.
Jou either have traffic or space.
Mobile stations ae not affected, unless they want to use more than 5 hops, that
will become 5 hops and not more...
More space on APRS
Black-hole coverage.
A digipeater in the APRS network can come and go. Problems arise when too many non-intelligent digipeaters are in a small area. This can easily happen in cities because of the dense population and lots of inadequately covered areas that appear in such areas due to buildings. These building blocks direct access to the nearest WIDE.
A station in such a 'black-hole' needs in that case a digipeater in the neighborhood which will convey signals from the station to the WIDE and which digipeats signals from the WIDE to the station.
Signals from the WIDE which are repeated by the "gap-fill" digipeater do not need to be digipeated once more by other digipeaters; those other digipeaters can pickup those signals already directly from the WIDE. The signals from the local station however should be digipeated; at least by the WIDE!
With DIGI_NED a port can be assigned "local:". Data that is send directly to the digipeater will be digipeated normally on a local port; there is no difference with non-local ports. Data which is not directly send to DIGI_NED but first passed through another digipeater, for example the aforementioned WIDE, will on the local port be transmitted with a truncated "via" list; digipeaters in the "via" list which are not "used" yet are removed. This way another digipeater will not handle the digipeated data anymore (unless the other digipeater has an "digiend:" rule to pick up the data again).
For intelligent digipeaters this is not really needed; data from the WIDE will also been received by the other digipeaters in the neighborhood and when a digipeater retransmits the messages than those other repeaters will not respond because the data has already been handled before. When digipeaters in the area are however not intelligent than they would just digipeat the data once more. This will result in a lot of needless traffic. In that case the port of DIGI_NED on which the data is transmitted can be assigned "local:" so there are no digipeater calls left anymore on which surrounding dumb digipeaters could react.
I-gate usage with DIGI_NED.
Some people asked me if DIGI_NED would function as IGATE. Since DIGI_NED is build for DOS and Internet with DOS is not easy to handle, DIGI_NED can't. But that doesn't mean that you cannot use DIGI_NED with an IGATE under Linux. Linux - and any Unix - is following the Unix philosophy of having small building blocks with dedicated simple tasks (I dislike large monolithic programs on Linux for that reason).
Using this building blocks you can easily build a "loopback" connection with pseudo TTY's. On one end you can connect DIGI_NED, on the other end you can connect the IGATE software.
To visualize what I'm going to explain:
This is how this is set up:
First have the KISS module loaded (kissnetd creates KISS devices):
echo 'Starting AX25 loopback drivers'
modprobe mkiss
Then start "kissnetd" on 2 pseudo TTY's in background:
/usr/sbin/kissnetd /dev/ptyq1 /dev/ptyq2 &
sleep 4
Wait for "kissnetd" to be started, than take the other end of these pseudo TTY's - which act as KISS - and create two network interfaces which are related to two ax25 ports. In my setup this will create interfaces ax0 and ax1.
/usr/sbin/kissattach /dev/ttyq1 -l ldigi
/usr/sbin/kissattach /dev/ttyq2 -l lgate
Now I configure ax0 and ax1 and declare them as "up".
/sbin/ifconfig ax0 10.0.0.1 netmask 255.255.255.255 \ mtu 256 hw ax25 PE1DNN-7 up
/sbin/ifconfig ax1 10.0.0.2 netmask 255.255.255.255 \ mtu 256 hw ax25 PE1DNN-8 up
So now I have 2 ax25 ports "ldigi" and "lgate" which are connected to each other. Now you can run DIGI_NED on "ldigi" and have IGATE software take frames from "lgate" and send them over The Internet. Frames from
The Internet are send to "lgate" and enter DIGI_NED via "ldigi".
DIGI_NED will digipeat frames from "1k2" (from the radio via a BayCom modem) to "ldigi" and frames from "ldigi" are digipeated by DIGI_NED to "1k2" and will be transmitted that way. This should work just fine.
The sample /etc/ax25/axports file for this setup is:
There is a lot you can do with Linux so that's why I'm not sure I want to build an IGATE into DIGI_NED. There are a lot of building bricks to accomplish what you want. I hope this helps to give an impression on how you could setup DIGI_NED together with IGATE software.
Blocking I-gate traffic.
The "via_block:" rule can block traffic via specified digi's. It also considers calls in the third-party header. It only considders the most recent 3rd party header, not recursive when the embedded packet contains another 3rd party header.
Using DIGI_NED as a SAT-gate.
This topic is being prepaired.