> a.) then how would a new or offline IPIP station connect if AMPRGW were DOWN at the time?
This is not a task of AMPRGR but of portal.ampr.org
> b.) then how do I get routes from AMPRNet without a DIRECT CONNECTION tunl0 connection to AMPRGW?
As I wrote is is possible to deploy a second system that does the RIP announcements
> c.) what if I can directly reach 2 or more AMPR subnets (but not the Internet)?
We already have a large network of radiolinks running here in Europe, and I think also in some
other areas of the world. It does not rely much on the internet, except for DNS. I download
the ampr.org DNS zonefile daily so I have it available when we are offline.
> a.) AMPRGW is currently the only route announcer (but you address that elsewhere)
I think it is important because it is the only weak spot I can see.
> b.) Next, it's not the ideal route to all subnets
Why not?
> c.) this solution addresses the possibility of redundancy to other subnets, as well as AMPRGW
I don't understand. There already is full redundancy. We have a full mesh.
> In planning, it would probably be an alternative to IPIP, and not a replacement. Ideally, there could be a few regional gateways, other stations connecting to one or more regional gateway and to other end-user gateways.
That is how we run the network here. What is your proposed change?
Rob
> I host a 70cm echolink node and did not need to place that PC in the DMZ.
> I did need to forward UDP ports 5198 and 5199 to the PC running echolink. I don't
> remember whether I also forwarded TCP port 5200 or whether that "looked after itself".
You are right, only forwarding 5198 and 5199 UDP is sufficient.
The echolink program also makes outgoing connects to port 5200 on the central server but you
normally don't need to open or forward anything for that, it is just the normal outgoing NAT.
(there are instructions that mistakenly mention port 5200 to be opened, but the program is not
even listening on that)
Rob
We are planing on setting up D-Star gateway, so I am reading all I can
about it.
Here is exception form one tutorial regarding this:
"The router for the D-STAR gateway must support a LAN address of
10.0.0.1, with a full class ‘A’ LAN (subnet mask of 255.0.0.0)."
Is it just me or this is really strange to force this IP range which
will conflict with number of private networks, especially when there is
44net dedicated for ham radio use?
Pedja
YT9TP
Let me explain the whole 10.x.x.x thing for D-STAR.
Icom created this to meet concerns of the Japanese postal service, to help
mitigate the concerns of TCP/IP over D-STAR displacing the ISP monopoly.
In D-STAR, the digital data mode transports Ethernet packets (and in turn
TCP/IP) as a payload to D-STAR packets. Routing is done based on the
D-STAR addresses which are call signs plus an optional "Terminal ID",
essentially an 8 octet address.
If you are using the Icom G2 (or V1) gateway software it talks to the Icom
RP-2C controller over Ethernet using 172.16.0.x addresses. On the
controller you can add up to 4 modules. A module can be a D-STAR voice
repeater (2m, 70cm, 23cm) or D-STAR data access point (23cm 128kbps). In
theory then you could have up to 4 D-STAR data access points (model
RP-2D). As traffic from the RP-2D modules come into the gateway, it
assumes it has a unique IP address in the 10.x.x.x range (assigned by a
registration process), but routes according the D-STAR addresses. The IP
addresses are registered to attempt avoidance of address collisions. So if
I as 10.10.10.1 (K7VE) want to contact NN1XYZ (10.3.2.1), the gateway
software sends the Ethernet packets from D-STAR address K7VE to D-STAR
address NN1XYZ.
The 10.x.x.x addresses are also NATed out to the Internet if the
destination address is not in the 10.x.x.x range.
None of this is used if you are only doing Digital Voice over D-STAR.
Everything is routed by callsign and the voice packets do not encapsulate
any TCP/IP or Ethernet content (well you could but it is not standard).
Now the reality is G2 is closed and largely stagnant, it also runs on
Centos 5.x which is losing update support, many data facilities have
security concerns if you are hosting with them. The larger network is now
running on ircDDB (ircddb.net) using ircddbgateway (see Yahoo! group by the
same name).
ircDDBGateway is Open Source and is pretty agnostic on Linux distributions
as well as being available as a Windows application.
ircDDBGateway supports the Icom controller as well as a variety of
alternate controller options. I would strongly encourage any new D-STAR
install to use ircDDBGateway (or another ircDDB based gateway). You don't
have to use the Icom addressing scheme. The RP2C can be on a LAN address.
Client stations of the RP2D (ID-1 radios) can then use LAN/DHCP addresses
(including 44-net).
--
------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
> This is the local IP setting of the gateway.
> It expects to be connected to a router with 10.0.0.1/8 witch will NAT to the
> Internet.
> In other words, the D-STAR device has a default route via 10.0.0.1, that's
> all.
> No conflicts here.
Well, I agree with Pedja that it is an extremely unfortunate choice and that it would
have been much more convenient when it supported 44-net addresses or even an arbitrary
address on the LAN.
We are running several D-Star repeaters and this requirement makes it very difficult
to share resources. Even running multiple D-Star gateways on the same ESX system
is more difficult than it ought to be (when a single router is running in another VM).
Also note that this program has other strange requirements. It requires an
ancient CentOS distribution, for example. That is why we want to put it in some ESX VMs.
Rob
by Poland AMPRNet Co-ord. - Janusz HF1L (ex.SP1LOP)
Hi everyone..
I have a problem, from 3 months I use Debian 7.9 kernel 3.13.3
in part hamradio use jnos 2.0j and from the very beginning I have a problem in
kern.log
I have all the time such data:
/var/log/kern.log
...
Mar 20 08:03:07 server kernel: [1908060.719531] protocol 0002 is buggy, dev bcsf0
Mar 20 08:03:07 server kernel: [1908060.865694] protocol 0002 is buggy, dev bcsf0
Mar 20 08:03:07 server kernel: [1908060.885101] protocol 0002 is buggy, dev bcsf1
...
Mar 20 20:13:16 server kernel: [1951869.497517] protocol 0002 is buggy, dev ax0
Mar 20 20:13:18 server kernel: [1951871.496945] protocol 0002 is buggy, dev ax0
Mar 20 20:14:26 server kernel: [1951939.652479] protocol 0002 is buggy, dev ax0
Mar 20 20:15:53 server kernel: [1952026.478022] protocol 0002 is buggy, dev ax0
Mar 20 20:16:12 server kernel: [1952045.710541] protocol 0002 is buggy, dev ax0
Does anyone know how to fix that such messages was not ?.
--
73 de Janusz HF1L (ex.SP1LOP)
===== Janusz J. Przybylski, HF1L ====================
Poland AMPRNet Co-ordinator [44.165/16] from Mar 2003
=====================================================
Hi
Does anyone know what ports \ protocols needed to be open to allow ipip tunneling ?
The Idea is not to place the gateway in the DMZ in a home internet connection
when the gateway sit there /
Thanks Forward
Ronen - 4Z4ZQ
http://www.ronen.org
Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
www.ronen.orgronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
> It's getting the legacy allocations into the portal that's not
> making me happy. Admittedly, the process is painful but I didn't
> think there'd be too many since we've had several years to get
> things in. Rob's point about needing some kind of bulk update
> process is well taken, and I'll look into that.
I think what I need is some way to feed a list of subnet/callsign pairs into
the portal (using a tab-separated file, XML file, json file, or whatever the
implementer feels most happy with) and it can create the subnet allocations
and set the type and the description of the subnet (to that callsign), but
leave the owner unset.
Then, when this particular OM creates a portal account and is validated and
accepted the normal way, those dangling subnet allocations would be automatically
attached to his account without me having to approve them.
Alternatively, rudimentary accounts could be created automatically so the subnets could
be attached to them immediately, but the completion with the details asked when
this particular call is registering would be deferred until that happens.
Important is that I can make bulk changes (like addition of a thousand entries)
as a coordinator without having to go through the current process of "registrant
fills a webform, I receive a mail and have to go to the portal and add/change
some fields to approve it" for each and every of those subnets.
It would be nice if there also is a way to process a callsign or allocation
change this way (delete old still dangling subnet allocations and create new
ones with different address or different callsign from a batch file).
This because we are in the process of building new nodes and need to renumber
some areas, which could contain entries that are not yet claimed by the owner.
Furthermore I would like to have the capability, as a coordinator, to change
the address and owner of an already allocated subnet. I can now change the type,
description and notes of an allocation, but not the address or user it is allocated to.
(this would not need to be a batch operation, just an addition to the existing
"Coordinator: Network Allocations" screen would suffice)
Rob
