44net

44net@mailman.ampr.org

4 participants
3196 discussions

Re: [44net] Uncle "google" in hamradio network ?
by Steve L 25 Mar '16

25 Mar '16

Thanks for the info. Looks like the info I need to use it for our purposes. Some time back there was a resource list that Jim Fuller maintained that was handy to list what was all out there. >HiHi >Not the whole one, for shure. >Just your "local area" and then report to the yacy network. > >Have a look here after google translated it for you ;-) >http://www.amateurfunk-wiki.de/index.php/Suchmaschine > >73 >2MIC

2 1

Re: [44net] Uncle "google" in hamradio network ?
by Steve L 25 Mar '16

25 Mar '16

I just recently completed an nmap of the routed portions: http://kb9mwr.ampr.org/public/nmap/030516routed.txt http://kb9mwr.ampr.org/public/nmap/030516nmap.txt I did the same thing a few years back but there was that IPIP,<-> BGP problem I too have yacy installed. I just started it back up. I am not to familiar with it, how do it get it to crawl the amprnet?

3 2

Re: [44net] Uncle "google" in hamradio network ?
by Steve L 25 Mar '16

25 Mar '16

No, and I'll admit that. That is why I'd like to hear more about how to configure yacy. But since there isn't a search engine or otherwise way yet to get an idea what is on the amprnet and what people are doing on the address space, I couldn't really think of any other way. The links below will only be active for a short time, as it's really only meant for 44net folks to get an idea. Steve >> http://kb9mwr.ampr.org/public/nmap/030516routed.txt >> http://kb9mwr.ampr.org/public/nmap/030516nmap.txt > >> I am not to familiar with it, how do it get it to crawl the amprnet? > >Is this wise? >- Brian

1 0

Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
by Rob Janssen 25 Mar '16

25 Mar '16

I don't understand your consideration of "moving from a star to a mesh". We ALREADY have a mesh! There is no load to be removed from AMPRGW other than the routing from/to internet for those that are not directly BGP routed on internet. When you want a solution for the "single point of failure" for RIP announcements, the simple solution would be to deploy a second RIP annoucer elsewhere, that sends the same information as AMPRGW, and takes over when AMPRGW does not send those announcements. Of course it still needs to be fed with the same topology information, so it could be tricky to get a solution that does not have any single point of failure, but your solution of doing BGP over tunnels instead has such information embedded in the static configuration of all the peers, which is even more difficult to manage. So it is not really clear to me what such a change really would achieve what we do not already have. What is the status of usage of AMPRnet addresses in HSMM? In the past they used RFC1918 addresses that were automatically allocated. I believe newer versions can use static addresses that could als well be from NET-44. Is this already in wide use? Rob

2 1

Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
by Rob Janssen 25 Mar '16

25 Mar '16

> 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

1 0

DMZ or not?
by Rob Janssen 24 Mar '16

24 Mar '16

> 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

1 0

Re: [44net] ampr-ripd for openwrt
by lleachii＠aol.com 23 Mar '16

23 Mar '16

http://44.60.44.10/amprnet_docs/ Should be available at this time to the Internet at-large. - Lynwood KB3VWG

24 82

D-Star
by Pedja YT9TP 23 Mar '16

23 Mar '16

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

4 5

Re: [44net] D-Star
by K7VE - John 23 Mar '16

23 Mar '16

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>

2 1

Re: [44net] D-Star
by Rob Janssen 23 Mar '16

23 Mar '16

> 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

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net