44net

44net@mailman.ampr.org

3194 discussions

Re: [44net] An apology for the Internet from the people who built it
by Rob Janssen 25 Apr '18

25 Apr '18

> "from the people who built it". Really? Gee, I don't remember any of those > names back in the early 80s (except for Stallman, but Emacs is not the > Internet). I fully agree! When I saw the list I immediately thought "those aren't the people who built the internet!" Not even the world wide web. Maybe Web 2.0.

2 1

New Mikrotik Vulnerability
by Nigel Vander Houwen 23 Apr '18

23 Apr '18

Hello All, We’ve (HamWAN) become aware of a new vulnerability on the Mikrotik devices that could allow an attacker to grab passwords off of the devices. If you block WinBox access you should be safe, but I’d recommend upgrading as soon as possible as well. More information about this vulnerability, as well as what versions are impacted, and what the patched version numbers are, are available from Mikrotik here: https://forum.mikrotik.com/viewtopic.php?f=21&t=133533 <https://forum.mikrotik.com/viewtopic.php?f=21&t=133533> Thanks, Nigel

1 0

Re: [44net] Echolink proxy/relay hosting
by Rob Janssen 22 Apr '18

22 Apr '18

> I found your C program in your follow up emails so seemed like I > should have everything I need. Sorry for the confusion, initially I > thought i needed to contact you for the C program. It probably wasn't clear in my first message... there is no need to contact me to deploy Echolink PROXY servers, the C program has been on my server for a long time (others are using it as well) and it can be installed on AMPRnet or commercial IP addresses alike. However, there are already quite some proxy servers and there is no immediate need for new ones, although they are always welcome. The call was mainly to get a number of new RELAY hosting sites, as there are currently not enough of them. Running PROXY servers is a good way to get some experience using the program, making sure it is started automatically and remains running, arranging for the extra addresses on the system (I do that using a script that does "ip addr add 44.137.75.$i dev eth0" in a loop, but it can be handled via the native network management of the distribution just as well. just don't create an extra interface for each) Once that is all clear and comfortable, RELAY servers can be configured (about 10, but in such areas as the US west coast maybe 5 is better as there are several volunteers now) and then you can contact me or K1RFD with the IP addresses so that they are going to get registered so they are really used. This is not required for PROXY servers, these register themselves automatically. Rob

1 0

Re: [44net] Echolink proxy/relay hosting
by Rob Janssen 22 Apr '18

22 Apr '18

> I like to help with this as well. Please let me know the details on how to > setup your C program. I know I am a bad writer, but I'm afraid you have to do with what is already in the README file and what I explained here on the list. Note it isn't really a beginner project, it assumes you are familiar with running a Linux system and compiling your own software on it. As a baseline, you are supposed to know what to do when you find a .tar.gz file and seeing that it contains a README, a .c file, a Makefile and an example configuration file. When there are obvious omissions, I am willing to update the README. Rob

2 1

44net IPIP tunnels may now be illegal in Russia
by Brian Kantor 22 Apr '18

22 Apr '18

44net IPIP tunnels may now be illegal in Russia. This is really not news, in that it's almost a year old, but I just became aware of it: https://www.bleepingcomputer.com/news/government/russia-passes-bill-banning… Russian users of 44net should be aware of this. - Brian

1 0

Echolink proxy/relay hosting
by Rob Janssen 22 Apr '18

22 Apr '18

For some time we have been hosting Echolink proxies and relays on the system that is the gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use a /24 subnet for that. Such proxies and relays facilitate the use if Echolink by users and repeaters that are behind NAT or are otherwise firewalled. About 100 repeaters around the world use our proxies, and over 600 users of the mobile app use our relays. Each Echolink proxy and relay requires a different IPv4 address. This can be a static address on internet, but often people have no /24 to spare for such things. AMPRnet provides the required address space. (unfortunately with an unintended side-effect, but in general it works well) For performance of the Echolink system it would be best when there are more places with a similar setup, distributed around the globe. Are there other BGP-routed sites outside Europe where such a service could be run? I have written a C program for this, that uses considerably less resources than the original Java software. On a 2.67GHz XEON server it causes a load around 0.05 for our 200 proxies and 10 relays. Of course it makes some network traffic, about 3 GB/day for the relays and similar for the proxies. When you have your gateway located in a suitable datacenter and are interested in such a setup to facilitate Echolink, please send me an e-mail and I can provide more info. Maybe we could even get the whole echolink.org infra hosted on AMPRnet space, which would solve the problem there now is with partially connected AMPRnet networks. (when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet disappears) Rob

14 20

Re: [44net] Echolink proxy/relay hosting
by Rob Janssen 22 Apr '18

22 Apr '18

> This is not a special problem for the 44.190 space. It affects every > direct connected 44 announcement for those users that cannot use IPIP > tunneling because they don't have a plain IPv4-connection. In Europe it > is very common to give normal customers a so called "DS-Lite Connection" > or a plain IPv6-connection. Everything that must be reached in the > IPv4-world from those custumers sites mostly goes through this ugly > "carrier-grade-nat (CGN)" which in most cases doesn't work very well for > our special needs. IMHO the preferred solution for this is to setup regional routing points where IPIP (and preferably BGP announcement) is possible, and where those users that have limited internet connections can connect via a VPN technology that still works for them. This way, their HAMNET traffic can be forwarded untranslated. It is the method that we use, and various others do it as well. As was shown before on this thread, VM/VPS services that can be used for this are widely available. And those do not suffer from having CGNAT or dynamic addresses. At least not yet. Rob

1 0

Re: [44net] Echolink proxy/relay hosting
by Rob Janssen 22 Apr '18

22 Apr '18

> Wasn't the idea to 44.190.0.0/16 subnets available via BGP? If so, why > would there be NAT? Of course for directly connected networks there will be no NAT, but there are those networks that are connected to internet via consumer internet connections (and no IPIP tunneling) and the traffic from those networks to the 44.190 space will pass through NAT routers. Rob

2 1

Re: [44net] Echolink proxy/relay hosting
by Rob Janssen 21 Apr '18

21 Apr '18

> I've run several proxies for years, but for this new venture, I will > have to go over to the proxy software that was mentioned here > yesterday. Should free up a bit of RAM to do so, Java is a hog! :) The Java proxy server requires 25-30 MB of memory for each instance, which can run 1 proxy. The C version I wrote uses about 2.5 MB of memory to run 200 proxies and 10 relays in a single process. Rob

2 1

Re: [44net] Echolink proxy/relay hosting
by Rob Janssen 20 Apr '18

20 Apr '18

> Well, I have a VPS in Melbourne, which runs IRLP reflector 9550, among > other things. I currently have a /28 of public (non AMPR) IPs, which > are fully utilisied by Echolink. I could ask about getting a /24 BGP > announced, so I could participate. That would be great! You can start getting a /24 (from your country network or from that 44.190 network, that does not really matter when you are not close to another network like Germany) and setup your system to be on the tunnel mesh. Then you can experiment with the software. In parallel you can get your BGP announcement fixed. > One thing I am not seeing addressed by this proposal is what happens > with the nodes themselves, which are the the most problematic part of > Echolink (and IRLP) due to their incompatibility with NAT (requiring > port forwarding to work at all). That is what the whole proxy/relay thing is about. A proxy lives on a system with unlimited UDP access from/to internet (port 5198/5199) and it also listens on port 8100 (default) for TCP connections from a repeater, link or user who is behind NAT. When a user connects it relays the UDP traffic from those ports to the TCP connection, and vice-versa. So it solves the NAT problem for that specific user, while preserving full functionality (the user behind the proxy can connect to several other stations and accept connections from other stations all at the same time). But a proxy can be used only by one user at the same time, that is why you want like 200 proxies. Proxies register themselves at Echolink.org, and a user wanting to use one can retrieve a list from the server and select one, some clients can automatically pick a non-busy proxy from that list. The Echolinks server sorts the list by geolocation distance to the requester, so your own proxies will appear at the top of the list. At least, when you have setup geolocation properly for your subnet. When you carve your subnet out of a country network this will work automatically when your coordinator has properly registered the country network. When he/she hasn't, your subnet will likely appear as located in San Diego, California. But you can fix that by sending a couple of registration requests to the most important geolocation providers, easlily found by googling for IP geolocation. This is another disaddvantage of the 44.190 space: you will certainly have to solve this problem yourself. A relay is a bit different. It allows only limited functionality: only outgoing connections, only a single destination at a time. It is used by default by the phone apps. A relay can serve multiple users at the same time, but the group of users can only connect to different destinations. When a user of a relay wants to connect to a destination (e.g. a popular repeater) that has already been connected by another user, the relay will refuse the connection and the app will have to hop over to another relay to try it there. That is why it is suggested to run 10 relays at each site. Relays are not automatically registered. They need to be manually registered at Echolink, who will put them in a geo DNS so users will get their address when querying relay.echolink.org and being closest to your relay. Try a dig -t a relay.echolink.org to see what it returns for you (most likely it will return our relays at 44.137.75.x in Amsterdam, not really close for you :-) That is what we are trying to solve by getting some more relays deployed. But first you can experiment with proxies, you can turn them on or off at your own will. Once you have started to run relays you need to take care that they remain running or when you want to quit, to tell that to the Echolink people so they can take them out of the pool, so users will not have to try to reach them in vain (until they try one that still works). Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net