Last Heard
JFindU D-Star Maps
Repeater Directory
D-Star Solutions
Watch D-Star Grow
Updated Site
Joining The Network (Now Automated)
(Updated 01/20/2013
Japan D-Star Repeaters
IPhone App
ARVN Programimg D-Star Radios Pt 1
ARVN Programimg D-Star Radios Pt 2
(IC91/92 ID-800)
Nifty E-Z Guide to D-STAR Operation
The first published book on D-Star!



Adding a Gateway Ver 2 D-STAR Gateway to the Network


This page is designed to give you an idea of what's involved in brining a new D-STAR Gateway onto the network. The overall process is very simple, if you'll pay attention to some key points. While this document will not attempt to replace a Gateway Certification Course, it will address most of the major points.

Equipment and Location

The Gateway requires a computer with at least two Ethernet ports, a minimum of 512 MB of memory, and a recommended processor of at least 2.4 GHz. This computer needs to be at the repeater site with the repeater. It's possible to remotely locate the Internet connection if absolutely necessary, but the network segment between the RP2C controller and the Gateway is very sensitive to latency. Because of this, we recommend leaving the gateway at the repeater site.

Internet Connection

OK, here's the bad news - you MUST have a static IP for use on the D-Star network! D-Star is designed around static IP addresses. Workarounds like "sticky" IP addresses or Dynamic DNS are not applicable in this environment. You'll need speed at least equivalent to good DSL.

Operating System

The RS-RP2C manual suggests Fedora Core 2 or Redhat 9 Linux. Most of us are running Fedora Core 4, which we know is old. We do have FC5 and FC6 running, but they definitely require more attention than FC4 to install. The added security features seem to conflict with the Gateway. The gateway is especially sensitive to iptables configurations, in many cases refusing to even load. CentOS has been explored and works well also. Ease of installation is expected to improve in the near future.

System Maintenance

This is a sensitive subject for most administrators. The D-Star Gateway design does not allow for easy removal of data in the system. Why is this a Big Deal? Indulge us just for a moment here...

Every Gateway synchronizes its database with every other Gateway, every day. This also happens anytime an administrator adds a new user and executes a "push_mng" command, or whenever the administrator needs to execute a "reserve" command to obtain another block of 32 addresses to assign to new users. In normal operation, this shouldn't be an issue.

But what happens if a Gateway has had to change its IP address (changing ISP's, location, etc.)? This old address is still in the table, and every Gatewat in the network will attempt to synchronize with that old address. Of course, there's nothing at that address now, and the operation "times out" after 5 minutes. Now, think what happens if there is more than one of those invalid entries in the list of gateways. Yep - the response to a command can take a REALLY long time!

Well, we just delete the bad entry, right? Not quite. Since every Gateway shares all of its information with every other Gateway, we have to remove that bad entry from all of them AT THE SAME TIME. The only way to accomplish that is to follow this process:

  • Shutdown the Gateway processes on every Gateway at the same time
  • Remove all data from each system
  • Write out the data on the centrall TRUST_SERVER
  • Edit the data, making the necessary changes or deletions
  • Read the data back into the central TRUST_SERVER
  • Restart all of the other Gateways
  • When they restart, they pull corrected information from the TRUST_SERVER

If things really worked this way, maintenance would be relatively easy. With a small number of Gateways on the network, coordinating this effort is pretty simple. With a growing number of Gateways, literally around the world, manually coordinating them all is almost impossible. But remember, if even one Gateway doesn't execute this process at the same time, its data will be the old data, and the old data will repropagate throughout the network, rendering the exercixe futile.

The Good News is that a group of administrators has come up with an automated process that allows this to be much more reliable. It's acocmplished by asking each Gateway in the network to install a set of scripts that check a central site for cleanup schedule coordination, and then executing the appropriate steps at the scheduled times. This effort has dramatically imporoved our network performance and reliability.

Because of the situation just described, we consider running these coordination steps to be a requirement for joining the network.

Multiple Networks

There are multiple D-Star networks in operation today. They do not share anything between networks. Communication between networks is not possible. Because of the synchronization described above, as soon as information about any one Gateway in Network A is added to Network B, the Gateways all automatically synchronize, and the two networks are then one.

There is nothing inherently good or bad about having multiple independent networks. As long as everyone is aware of the restriction described above with communicating between networks, things are fine.

Those of us who were early adopters of the Gateway fumbled our way through learning many of the features and restrictions of the Gateway. To make things easier on those who followed, we recommended a Gateway Certification Course for new trustees, in order to minimize the impact to the network of errors made by new administrators with erroneous assumptions about how things "should" work, versus how things really do work with the system. Many of us with technical or networking backgrounds found it difficult to release our assumptions, and to accept the design for what it is. Since mistakes on one Gateway impact every other Gateway in the network, we chose to require some training.

We do not expect everyone in the world to go through the existing training course. Many new owners will say that "I know networking - I don't need a training course!" Our experience has been that this almost always results in our executing a network cleanup to remove the errors that come from things like this. Fortunately, the cleanup scripts running on all the gateways make this process much less painful for everyone.
Administrators Forum

We have a Yahoo! Group set up form Gateway Administrators. There's no secret information there, but we do try to use that as a place to discuss network coordination and Gateway-specific things, with participation limited to those who are responsible for Gateways on the network. If you have a Gateway on the network and are not a member, please contact Jim McClellan, N5MIJ, via K5TIT.org to join the group.

New Gateways

Our current procedure for bringing a new Gateway online is for the new Administrator to perform a test with the D-Star Technical Support Group at ICOM. When that test is successfully completed, the cleanup scripts are installed on the new Gateway, and the notification is sent to the Network Coordinator for the D-Star network with contact information for the new Administrator. The Network Coordinator will then contact the new Administrator with information about the network TRUST_SERVER, and describe the final processes for bringing the new Gateway online.

We do expect these processes to change, as our experience grows and as the product changes. As new versions of the Gateway become available, we expect to see the system become less sensitive to errors, and correction of those errors to become easier. At that point, many of these procedures will no longer be necessary.


We know that everything we do in D-STAR will be subject to change as the technology grows, and as our experience improves. We ask that you be patient with us as we all learn together to best implement the capabilities of D-Star. Each regional area will develop their own training and implementation criteria. Many will join a common network. We'll find better ways to manage things. We'll all learn together.

And along the way, we're going to have FUN!

Welcome to the future.
Welcome to the FUN!

© Copyright D-StarUsers.org, All Rights Reserved.
Last Heard and DStarMonitor Disclaimer