44net May 2016

44net@mailman.ampr.org

39 participants
21 discussions

Re: [44net] was Verifying the identities of IP coordinators
by Steve L 02 Feb '17

02 Feb '17

First I wanted to mention I am glad to read Bjorn's message about adding some content to the network. Keeping in contact is key. Be that a coordinator or any host on the amprnet. Seems every few months on here we are discussing how someone is sending out random packets, and a straight forward way to get a hold of people would be helpful. Some time back it was brought up to have a whois server or something like that. I bet I can guess the status of that. As for everyone having an ampr.org email address, perhaps a forwarding service like the arrl.net addresses? Then there is the possible spam problem, and the fact that someone would need to set up such a service. Overall a lot of good ideas are brought up on this list, so few ever happen. The only solution I am offering is everyone should help spread the word and try and get more people involved with moving this network forward. I wish I had better coding skills. One of the core problems at least in my country where the ampr/44net space is not well utilized is the lack of higher speed equipment to build a network. You really have to be part of a well organized club with site connections to do anything microwave on any big scale from what I have seen.

7 7

rip down ?
by Maiko Langelaar 17 Sep '16

17 Sep '16

Did we loose the rip broadcast ? Maiko

5 5

Looking for assistance setting up IP Ham system
by Arnold＠rogers 02 Jun '16

02 Jun '16

Can someone please direct me to the right place where I can purchase a complete kit so that I can setup an IP Ham network system. I would like to experiment with using using the 44Net as a fall back network in times of disaster. Any assistance / direction will be very appreciated as I am new at this. Thanks Arnold Villeneuve www.networkologist.com <http://www.networkologist.com> Change is the end result of all true learning.- Leo Buscaglia

11 19

Re: [44net] AMPRNET katency in VOIP connections ?
by Rob Janssen 01 Jun '16

01 Jun '16

> The fact is that, actually the repeater is networked to the EchoLink > server and this can be obtained ONLY by using the commercial > IP number, i.e. IP address 79.47.199.234. Look at our repeaters, e.g. PI2NOS It is registered on the Echolink system using its own address 44.137.72.130 (pi2nos.ampr.org). Therefore this problem does not occur here. > the incoming IP results 44.137.41.97; so I understand that the > internet server act as the real gateway in a similar way as our > ampr.org gateways. It function very OK! Yes, for "normal traffic" it works OK. But not for Echolink. This is because Echolink has a directory server that registers your repeater by IP address, and this address does not match the actual address. When you get connected by someone from plain internet, it works OK because the route back is through the same NAT router, where you have defined port forwarding for the 5198 and 5199 ports, and the users sees the same translated address as the Echolink system registered. However, when I connect from my address 44.137.41.97, the repeater or another part of the system thinks it is being clever and routes the traffic through a IPIP tunnel, the address does not get translated, and the connection fails. The quick way to solve it is to give your repeater some RFC1918 address (10.x.x.x, 192.168.x.x) so its traffic is always forced through the NAT router. Alternatively, you can setup some policy routing so the Echolink traffic is always sent to the NAT router, not routed directly. Then you can still use AMPRnet on the same computer for other things. The way we solved it here is by applying for BGP routing of our subnet, so our net-44 traffic is routed directly on internet and it is no problem to run an Echolink repeater on it. (the subject of this thread: will routing through UCSD cause problems with VoIP. yes it will, but we don't route through UCSD so we don't have that problem) Rob

4 5

smtp (port 25) filter ?
by Niall Parker 31 May '16

31 May '16

Is port 25 now being filtered within the tunnel network ? Submission (587), ssh (22) and http (80) appear to be OK (Internet -> 44 net) ... Niall

2 4

Re: [44net] AMPRNET katency in VOIP connections ?
by Rob Janssen 31 May '16

31 May '16

> Subject: > Re: [44net] AMPRNET katency in VOIP connections ? > From: > "'Gustavo Ponza'" <g.ponza(a)tin.it> > Date: > 05/30/2016 07:12 PM > > To: > 44net(a)hamradio.ucsd.edu > > > On 05/30/2016 05:55 PM, Rob Janssen wrote: >> (Please trim inclusions from previous messages) >> _______________________________________________ >>> I don't know how they do the job... but as all of you can see, >>> also iPAD/iPhone can do it by using my small ampr.org facility :) >> >>> 73, gus >> >> Which repeater is this log from? It is on an AMPRnet address? > > It is from IR0AAB (ER-IR0AAB). It is on (or better, it should be on) > 44.134.32.240/44.208.58.1 Ok but it registers on Echolink using IP address 79.47.199.234 So there is some NAT between its 44-address and internet! This is no problem as long as the repeater always routes its traffic via that NAT, but in practice those operators often route 44-net traffic directly and then it does not work. I have tried to connect it from my 44-address and indeed it fails! I connect to the node on address 79.47.199.234 as directed by the Echolink server, and I get replies from 44.134.32.240: Spurious audio packet received from 44.134.32.240 So I cannot connect that repeater from AMPRnet. Rob

2 1

Re: [44net] AMPRNET katency in VOIP connections ?
by Rob Janssen 30 May '16

30 May '16

> Subject: > Re: [44net] AMPRNET katency in VOIP connections ? > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 05/30/2016 06:25 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > As far as I know there are no active AMPRNet users in Asia. > - Brian > > On Mon, May 30, 2016 at 05:55:47PM +0200, Rob Janssen wrote: >> >It would be welcome when a volunteer a lot more east (near Japan/Korea/Thailand) >> >could setup another set of Echolink relays. This requires a Linux machine >> >with 5-10 IP addresses available to it, either plain internet or BGP-routed AMPRnet. A host somewhere in a datacenter with a /28../24 subnet would be OK as well. There are a couple of Echolink proxies in the far east, e.g. from JH1PGO but I have been unable to contact the operator. Rob

1 0

Re: [44net] AMPRNET katency in VOIP connections ?
by Rob Janssen 30 May '16

30 May '16

> I don't know how they do the job... but as all of you can see, > also iPAD/iPhone can do it by using my small ampr.org facility :) > 73, gus Which repeater is this log from? It is on an AMPRnet address? Those 44.137.75.24x addresses are our Echolink relays that serve the mobile users in this part of the world. It would be welcome when a volunteer a lot more east (near Japan/Korea/Thailand) could setup another set of Echolink relays. This requires a Linux machine with 5-10 IP addresses available to it, either plain internet or BGP-routed AMPRnet. When some 20-200 addresses are available, it can also run Echolink proxies. A combined proxy/relay server written in C (1000 times more efficient than the echolink.org Java version) is available on my site: http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz Bonus points when you find the race condition that makes it sometimes leak proxy instances when it is rapidly scanned by a web proxy scanner :-) Rob

3 2

Re: [44net] AMPRNET katency in VOIP connections ?
by Rob Janssen 30 May '16

30 May '16

> The easiest way would be to put an Echolink system server on a 44.x.y.z > IP... > Anybody working on this? > This will avoid NAT and proxies, but problem with bandwith and latency > staies the same if serveral "44 islands" are connected via tunnels. > You then have to consider the bandwith of the tunnels and the > performance of the peers. > Micha, DD2MIC The main issue is that many users of the system are on plain internet and so the Echolink repeater has to be on a BGP-routed subnet or the users will all enter via the UCSD router. When you are not on a BGP-routed subnet I think it is better to use a proxy to register using the plain internet address, so at least the user traffic remains local and does not all go via UCSD. Rob

1 0

Re: [44net] AMPRNET katency in VOIP connections ?
by Rob Janssen 30 May '16

30 May '16

> The basic idea would be that AMPR to AMPR traffic is a go since it is > tunneled directly. > Public IP to AMPR is a no-go for tunneled networks. > They have a public Gateway IP anyway, so you should use that one for access > from the internet. > Marius, YO2LOJ When you use Echolink from within AMPRnet but want to use a public IP you should be very careful how to implement it. Some people configure an Echolink repeater on an AMPRnet address and then route the traffic to some gateway where this address is translated using NAT. However, this does not work correctly! The Echolink repeater will register itself with the Echolink system server which is on public internet, so the registration address in the Echolink system is the address of your NAT router. But internally, the repeater has a 44.x.x.x address so when someone from a 44.x.x.x address connects the reply will come from the wrong address and the connection does not go through. This manifests itself when some other systems are natively on AMPRnet not using NAT. For example, here in the Netherlands we have several repeaters with a true AMPRnet address that is BGP routed, and we also run several Echolink proxies and relays on AMPRnet addresses. In neighboring Germany, the NAT method is often used, where the repeaters have a 44.x.x.x address but connect to the Echolink server via NAT. As a result, no connections between the repeaters in these two areas are possible, and worse: people using our Echolink proxies and relays cannot connect to German repeaters or users. It can be solved by not using NAT to translate the Echolink traffic to public addresses, but instead run an Echolink proxy on the gateway system which converts the internal AMPRnet address of the Echolink repeater to the public address of the gateway. Unfortunately only a single proxy can be run per public IP address, so a "normal" gateway with a single external address can only host a single repeater. To solve this, a number of proxies can be run e.g. in a datacenter where an IPv4 subnet is available for them (more and more difficult, of course!). This has now been done in Germany. The disadvantage of this solution is that all users that are on AMPRnet still connect to the outside address. On a BGP routed AMPRnet network where no proxies or translations are used, local users can connect the repeater directly. Rob

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net May 2016