44net

44net@mailman.ampr.org

3194 discussions

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

20 Apr '18

> I think original routing methods are not easy to use and have drawbacks : > - eBGP is not available to end-users, or even to small teams or repeater > operators. It requires network skills, and access to telecom operator > data centers. I think end-users or teams should not try to use eBGP unless they want to do it as another learning project as part of their AMPRnet gateway. Announcing your AMPRnet allocation on internet is simply a matter of telling your colocation/VPS hosting company that you have portable address space that you want to announce on internet and route that to your server or router. That is a standard change in their portfolio, they do that for lots of other customers and for them it is a simple matter of configuration in their existing network. They know how to do it and they already monitor it. When you do it yourself, you will have to get an AS, peering, setup your router, cope with the vast amount of routes and the processing and storage they require, etc. Not something to embark on lightly, and usually not necessary at all.

4 6

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

20 Apr '18

> As far as I can tell, one of them (VE7ALB) is in Canada, and the > other three (KK6NEI, K4JH, W6KWF) are in California and plan to > locate their Echolink relays in the same data center in Fremont, > California. I wonder if it would be beneficial for those three to > pool their resources in some way? I agree that is not an optimal situation. It would be better to cooperate and maybe setup 3 or 5 relays each, and some proxies. It can be good to have some redundancy but it makes little sense to have 30 relays and 600 proxies all in the same state. I wasn't aware that this is the case, the USA is big and relays in California, New York and Texas would have been fine :-) Rob

1 0

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

20 Apr '18

> I just applied for a /24 out of 44.190/16, to help with this endeavor. > I’ll be announcing the prefix out of a commercial datacenter in Fremont, CA under ASN 7247. I advise you (like is best for everyone who announces 44Net space on BGP) to make the system part of the IPIP tunnel mesh as well. I.e. make a tunl0 interface and run ampr-ripd on it, register it as a gateway using an extra IP address outside the /24 subnet. Add only the routes received over RIP, not a default route to ampr-gw. Of course you have a default route to your BGP router. This ensures that you are reachable for all AMPRnet hosts as well as normal internet systems, even when they cannot route their traffic transparently over internet themselves. It looks like we have 3 interested parties in the US and Canada, which would certainly help out for now. It would be nice if someone in the far east or Australia could join in. We always have a large number of users from Thailand, for example. Rob

3 2

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

20 Apr '18

> One of the main purpose of amateur radio is to experiment new things. > Then, I think it's globally a good idea to experiment new routing > variants, that are more suitable with today and tomorrow usages. Of > course, this will raise compatibility issues and routing problems. But > that's our job to find solutions :-) In general I think that is true. But in this particular case, that experiment is just there to work around unfortunate decisions made in the past. I can understand that it is now a lot of work to re-work the German HAMNET to make it compatible with a plain routed address space, but I do not see it as my responsibility to jump through hoops instead. When it would be a simple change, I would not have a problem. But as it is now, it is just as much work for us to cover their irregularities than it is for them to adapt their network. In that case I favor the "clean solution". > Here, in Corsica, we'll try to adapt our home-made system (OpenVPN > tunnels to two central gateways, and OSPF routing through 10.0.0.0/8 > private addressing) to AMPR addressing. One of the main advantages is > that user connection is very easy (we developed a Plug and Play system > called "TKBox" : an OpenWRT router, which opens VPN tunnels to our two > data centers, in VPN pass-through mode). It's suitable for a remote > location such as our island, because our two data centers will be the > only points of connection with the outside world. All the specific > routing and firewalling has to be tone only there. That is very similar to what we do here on the 44.137.0.0/16 network and you will not encounter the difficulties of NAT when you do it that way. All traffic internal and outside of your network is just plain routed. We use OpenVPN only for end-users that connect to our gateway and get 44Net space but only over the tunnels. However, that is the "novice class" of AMPRnet, we really do not want users to connect that way forever. They should use radio links, and when no access point is available they should get together and establish one. And that is developing rapidly. Of course access points would ideally be linked to other access points via radio, but until their density is sufficient to make that possible we also allow a VPN connection to a central router located in the datacenter, either GRE or L2TP/IPsec, and we run BGP over that connection so it can be used for the connectivity to AMPRnet or as a backup in case their are problems with the radio link. Radio links have preference in the recommended BGP setup. In this network we have untranslated internet access for every station because we do not directly send traffic on a user's internet connection (only the tunneled traffic to the central router that forwards the encapsulated 44Net packets to internet). In my opinion that is the correct way to do it. Of course if you want to setup many gateways like that across a larger country, the practical difficulty is that you need to negotiate BGP routing in many places. It is so much easier to just give in on that and go out via NAT over some local amateur's internet connection. But it causes the problems that Jann is now facing. Rob

2 1

Fwd: Massive IP blockings in Russia
by Brian Kantor 19 Apr '18

19 Apr '18

[This has been forwarded to a number of mailing lists, but in case you haven't already seen it, you may find it of interest. This copy was received from the NANOG list. - Brian] Begin forwarded message: From: Alexander Isavnin <isavnin(a)gmail.com> Subject: [cooperation-wg] Massive IP blockings in Russia Date: April 17, 2018 at 1:36:33 PM EDT To: cooperation-wg(a)ripe.net Dear colleagues! I'm not pleased to inform you that RosComNadzor, a Russian Communication supervisory body, has started blocking huge ranges of IPs belonging to different cloud infrastructures, mostly Amazon and Google Cloud. Those ranges include: 13.52.0.0/14, 13.56.0.0/14, 18.184.0.0/15, 18.194.0.0/15, 18.196.0.0/15, 34.192.0.0/10, 34.240.0.0/13, 34.248.0.0/13, 35.156.0.0/14, 35.160.0.0/13, 35.176.0.0/15, 52.0.0.0/11, 52.192.0.0/11, 52.208.0.0/13, 52.28.0.0/15, 52.58.0.0/15, 54.144.0.0/12, 54.160.0.0/12, 54.228.0.0/15, 54.72.0.0/15, 54.88.0.0/16. Russian ISPs MUST fully block all traffic to such networks. The list is frequently updated and gets automatically propagated to ISP every once in a while, failure to block any address may result in 1500eur fine. The infrastructure listed above is being added to the blocklist under 'counter-terrorist and counter-extremist' order of the General Prosecutor Office, #27-31-2015/Id4082-15, issued in 2015 and often used for blocking an arbitrary unwanted content. The real reason for such blocking is an attempt to cut access to Telegram messenger, which refused to provide end-to-end encryption keys to the Federal Security Service (previously known as KGB). This is a case similar to San-Bernardino shooter's, where the FBI was denied access to the shooter's iPhone, but courts in Russia have made completely opposite decision. Telegram's infrastructure is being blocked by a different decision by RosKomNadzor, #2-1779/2018. Cloud infrastructures are being blocked for massive proxy and VPN hosting used to dodge messenger blocking. It is said, that more Apple and Google networks may be blocked soon for apps updates and push notifications delivery for Telegram. We hope to still have the global IP connectivity to keep you informed about how the situation develops. Do not be surprised if some of your services placed in cloud infrastructures will miss Russian customers. You can monitor the number of IP addresses, domains and URLs to be blocked in Russia at the https://2018.schors.spb.ru/ page (run by the famous ENOG community member Phil Kulin). Detailed information (also via API) is available at the https://reestr.rublacklist.net run by RosKomSvoboda civil society group. Kind regards, Alexander Isavnin Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ----- End forwarded message -----

5 6

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

19 Apr '18

> Thanks for posting this. I didn't know. The last I heard about that, it would be a block at the end of the address range.... because it would be easier to route "everything except this". Apparently it was changed again. (I also didn't know) Rob

1 0

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

19 Apr '18

> I actually have some server resources where I was considering hosting a large echolink proxy service for echolink users however I have run into issues getting fiber providers to bring the ip’s in for me to use.. So I am not sure what my next step should be considering returning my ip’s if I can’t seem to follow through. > By the way I have to use Java for minecraft servers so my 12 core 24 thread should easily handle a bunch of proxy servers.. However if you have some thing that is Linux based and works well I would be all ears to help out the community using the newer code if willing to share.. The proxy/relay server we use can be downloaded from my webserver: http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz It runs on Linux, and probably on BSD as well after some changing of sockopt names. We have been using it for a couple of years. There is one small race condition that I still haven't been able to locate, I plan to try to convert it from the use of select() to using poll() and hopefully get rid of that. But still it runs for months on end, sometimes losing one or two proxies that get stuck in the logon phase. It requires a system with a number of IP addresses that are routable to internet. They can be AMPRnet or other public space. Rob

1 0

Openwrt x86
by pete M 18 Apr '18

18 Apr '18

Hi! I have a dual Nic micro atx MB that I use as my main router on my 120/20 MB residential connection. I was wondering if it would be possible to have a 3rd nic (pcie) that could be use as the apmrnet gateway to hamprnet for my allocation. I dont want to have my local home net available on 44 net but if I need to hook up my segment to the internet I want it to be available. I am not bad on linux, but I am not a network engineer. Been playing with wds ap/station captive portal and modding routers. but this is just over my knowledge base. Anyone willing to help? Thanks Pierre VE2PF

5 13

Unable to rsolve host error in the portal
by R P 17 Apr '18

17 Apr '18

Hi I have entered new ddns.net name to one of the gateways i have installed and while pressing the save button got "unable to resolve host" error The name is resolvable ... Is the Portal lazy ? Any info is welcome Ronen - 4Z4ZQ

2 4

Meraki/MikroTik running ampr-ripd on OpenWRT
by lleachii＠aol.com 16 Apr '18

16 Apr '18

All, I wanted to inform you all - that I have successfully compiled and ran ampr-ripd on a Meraki (Power PC) and MikroTik (Atheros, the binary for my previous routers worked). I have included the PPC binary in the 2.3 TAR on my site (along with x86_64 and Atheros ar71xx). Its only dependency remains: libstdcpp. 73, - Lynwood KB3VWG

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net