44net

44net@mailman.ampr.org

3194 discussions

GL.iNet openWRT Rip44 support?
by Tracy Markham 30 Dec '20

30 Dec '20

I had reached out to the good people at GL.iNet and asked for help getting one of their openWRT routers to run my 44 net assignment. I referred them to the page explaining openWRT setup ( wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT) and requested they compile an executable for the processor in the router. Apparently they did it. It will be a bit before I can try to configure it but its a one click installation. It's available to anyone with a GL.iNet router product, just navigate to Applications -> Plugins and Update, then navigate to the R section. I have a screencap of all the dependencies it installed if anyone is interested. I reached out to them because I've failed on my previous attempts to set up an EdgerouterX for my assignment... I am by no means a network engineer, this is my foray into getting a gateway going. If anyone could confirm this works that would be great. If you're willing to help me get mine going that would be even better. Tracy N4LGH

7 10

Re: [44net] - > What about the future ?
by Rob PE1CHL 30 Dec '20

30 Dec '20

> Previously, we were talking about network topology. Here, we are talking > about applications. This is one of the drawbacks of the current 44net : > lots of applications are installed on 44net addresses, but there's no > current catalog, and no way to find them. > Maybe an idea of a project that can be handled by ARDC : a search engine > / catalog of all existing applications on 44net. I have been thinking about that before. My idea was to setup a search site which has a database of existing services, where a visitor could search by different attributes of an entry, where possible with a user interface that suggests valid values. So not a "google" style textbox where you can only search for things of which you already know the name, but also can "explore" and find new unknown things (e.g. a service type is a dropdown list or there is a page with all known types and links that you can click to search them). Now the major problem is "how do we keep this uptodate". It is quite common that someone newly active on the Dutch network experiments and installs something like a "HamServer Pi" and would register it in the database. But maybe after a couple of weeks he reprograms the Pi for something else and that entry would remain in the database and people trying to visit it would encounter a timeout. As I also do not really like systems that are constantly probing and scanning to find new services, my idea was to devise some way where a service would automatically refresh its entry by re-submitting it, and the search engine would only display entries that have been recently refreshed. (e.g. once per week or so) With such a system, the risk of stale entries is a lot less. But I have not yet devised a way to refresh entries without limiting the platform on which they can run (a Linux or Windows system can easily schedule a job that runs some program to post a form, but I do not want to limit too much what platforms can provide and auto-refresh services) Rob

3 8

Re: [44net] ipencap routing question -> What about the future ? (many messages in 44Net Digest, Vol 9, Issue 139)
by Stuart W. Card 30 Dec '20

30 Dec '20

On 12/29/2020 3:00 PM, 44net-request(a)mailman.ampr.org wrote: > > Today's Topics: > ... > 7. Re: ipencap routing question -> What about the future ? > (Toussaint OTTAVI) I would like to comment briefly on several points made in this thread. Has the 44NGN list been shut down? Concurrently with it being mentioned in this thread on this list, I received a message indicating I had been unsubscribed from that list. If lurkers like myself, who post very rarely, only when we feel we really have something to add, are welcome on the TAC, I will apply. Please take a look at the Host Identity Protocol (HIP) as one way of providing a persistent identity with a reputation (like a call sign) on the Internet, and dynamically establishing tunnels as needed to the corresponding IP addresses (despite changes due to DHCP or mobility). _Inter alia_, this would obviate moving from a resilient flat mesh to a fragile, congestion-prone hierarchy. It would also facilitate using 44 and non-44 addresses as needed. It uses strong crypto to mutually authenticate endpoints. Yes, HIP enables encryption, automagically establishing IPsec ESP tunnels, but it does not force encryption to be used _over the air_. See these IETF documents (neither experimental nor obsoleted) on HIP: RFC 4423 architecture RFC 5207 NAT firewall issues RFC 7401 HIPv2 protocol specification RFC 7402 ESP RFC 8002 certificates RFC 8003 registration extension RFC 8004 rendezvous extension RFC 8005 DNS extension RFC 8046 mobility RFC 8047 multicast a draft addressing how to deal with the issues in RFC 5207 https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ and especially the draft update to the 1st doc above https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ I have a ton of other materials I am willing to share explaining how HIP deconflates identities ("names") from logical locations (IP addresses used for actual packet routing) in the Internet, and naturally integrates cryptographic authentication of said identities, thereby solving many of the problems with current practice that motivated the "clean slate Internet redesign" hype several years ago. Our company has used it for lots of things, military and commercial, including mesh WANs. Currently I am working with various standards development organizations, government agencies, commercial product and service providers, _et al_, to standardize/promote its use to identify observed [unmanned] aircraft (and other cyber-physical systems) in a trustworthy manner, enabling authorized observers to immediately establish mutually authenticated communications with the parties responsible for their safe operation. There is 1 commercial product line that explicitly admits to being HIP based (some others formerly admitted that but no longer disclose the basis of their secret sauce): Tempered Networks https://discover.tempered.io/webinars/how-tempered-uses-hip-to-achieve-zero… There are 2 arguably usable open source implementations, one of which is being updated to HIPv2 and enhancements currently being standardized: OpenHIP https://bitbucket.org/openhip/openhip/branches/ 73, AC2WH (long ago WB2IEP) -- Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 <Stu.Card(a)critical.com> www.critical.com

2 1

Re: [44net] ipencap routing question
by lleachii＠aol.com 30 Dec '20

30 Dec '20

Roland, I guess the best way to answer this is, what Network Operating System are you using? - Windows - unknown (I last attempted in 2012) - *nix - only one tunnel need to be enumerated - Cisco - multiple tunnels are needed You can see this from the relevant Wikis. 73, - Lynwood KB3VWG

5 17

Re: [44net] ipencap routing question -> What about the future ?
by Rob Janssen 30 Dec '20

30 Dec '20

> I think Rob, PE1CHL, had some approach to offer 44net VPN access using > LOTW certificate for authentication if I remember correctly... Maybe he > could tell us more on how people where attracted to it. No, that is not me. I think it is a Finnish ham who is doing that. Over here we have OpenVPN access with locally issued certificates, not connected to any officially trusted source. When a Dutch amateur wants to use OpenVPN, they request a certificate (usually via me) and there is a script which generates a certificate for the requested callsign and makes an OpenVPN config file containing the correct parameters, the user certificate, and the CA certificate. When the user uses this to connect to the OpenVPN server, their IP address is retrieved from DNS (based on the certificate name which is their callsign), so they get their fixed IP address. A route is distributed via BGP to route the traffic to their OpenVPN connection from anywhere within the network, as long as the connection is up. While such a system could be used to "give all amateurs their own fixed IP address" (either via this locally issued certificate or with something like LOTW) I agree that there is little point in doing that "to make use of our IP space". Such a bank of allocated but rarely ever used addresses should not be considered "used" just for sake of "use it or lose it". Rob

1 0

Re: [44net] ipencap routing question -> What about the future ?
by Rob Janssen 29 Dec '20

29 Dec '20

> I don't know if "44NGN" is related to "DG8NGN", but Jann is a reference here : European HamNet already has thousands of nodes with iBGP routing, and he's the inititor of 44.190 routing policy. Lots of things already exist. I think we don't need to reinvent the wheel. Just find out the right wheel diameter that could be adopted worldwide No, this is not at all related I think. It was just made to mean "Next Generation Network". You are right that most of the things being proposed here already exist regionally. In the Netherlands we have a similar network to "European HamNet" except that it also routes from/to internet. (HamNet uses NAT routers placed at some points in the network, making the routing asymmetric) The proposed new topology would allow HamNet to join in and maybe get a bit better connected when desired. (and maybe resolving some of the difficulties that arise from the setup as it is now with combined BGP and IPIP/AMPR-RIP routing) Rob

2 1

Re: [44net] ipencap routing question -> What about the future ?
by Rob Janssen 29 Dec '20

29 Dec '20

> This is exactly the sort of thing we would like to have the TAC get together for. Why don’t any interested parties email me and maybe we can finally get this going. If we’re going to do this properly it will needs some structure and the extra noise it will generate should be moved to a separate list. > Chris - G1FEF That has been done before. Brian created the 44NGN list one of the previous times this discussion ran. I surely want to share my ideas about that but frankly I am not prepared to argue against the "what we have is good and we don't want change" gang. That is why I did not take part in what happened before on 44NGN. Rob

3 2

Re: [44net] ipencap routing question -> What about the future ?
by Rob Janssen 29 Dec '20

29 Dec '20

> The main issue is to separate regular users from a backbone infrastructure. > What is done in the infrastructure and how it is interconnected is not > important to the end user. It can be mesh, direct routing, whatever. > But the user needs to be able to connect his subnet to the backbone via > a (local) point of presence (POP) using a easy to use way, a way that is > supported by regular, or at least some commercial routers out of the box > or regular operating systems, without scripts and custom code running on > them. > From my point of view, It should be the choice of the operator of the > POP to decide what user access protocol they choose. For example L2TP is > still supported on many devices and is a good candidate, and even the > old PPTP will do. > There is no need to find a single universal solution for everything. If > the backbone works (and the current mesh could be the base of this > backbone, with simple users just opting out as other connection options > become available). I fully agree with what Marius has written there. We already operate such a POP, and there are others in the world. The implementation and connection options need not be the same all over the world, as long as some of the base requirements ("works behind NAT router, does not require to open ports or protocols in router, works well with a dynamic endpoint address") are satisfied by at least one of the offered connection options. And in my opinion, there should be the option to use BGP over the endpoint connections so that locally routed networks can be advertised over links to the POP. Operators can choose whether they want to offer a static routing option but of course it will limit the versatility and redundancy options. At the same time, I think it would be worthwhile to have a standard solution and deployment of that solution in datacenters all over the globe (in the form of a VPS so that no physical visits are required) so that everyone can have a good connection even when there is no local activity to setup a POP. Those would be managed by/via ARDC in a similar way as how the UCSD gw is managed now. This network of POPs would replace the current IPIP mesh as the connection option for users. The effort now spent on maintaining the IPIP mesh, RIP, gateway list can be spent on such a system instead and it will make it much easier for people to join and use the network. Rob

1 0

Re: [44net] ipencap routing question
by Rob Janssen 28 Dec '20

28 Dec '20

> I am trying to learn how ipip routing works by studying the various > setup scripts and wiki pages. Now I came upon a FAQ answer in > https://wiki.ampr.org/wiki/FAQ which I do not quite understand: > " > Can I just route all 44net traffic via a single tunnel? > No. The main AMPRNET gateway does not provide this functionality - you > must have a tunnel to each system you wish to contact. > " > Does this mean that I will need to create that many tunnel devices or > will a single device be able to handle all the required multiple tunnels? That depends on your device. A plain Linux system will not require multiple tunnel devices because on device tunl0 it can use the routing table to define the endpoints for all the different destinations. So you don't set a tunnel endpoint on the device, it is set in the routing table. And the routing table preferably is maintained by a program that processes the AMPR RIP packets. However, when you have some other router, like Cisco or MikroTik, this mode is often not offered and you *do* require a separate tunnel device for each destination (currently about 600...) It is all a bit outdated. I hope the community sometime soon decides to migrate to a somewhat more modern setup that does not mandate a full mesh tunnel network when users do not desire to have it. (i.e. establish a number of routers in datacenters around the world so one can connect to one or a few routers instead of to all individual end users, many of whom are not even operational) Rob

1 0

ipencap routing question
by Roland Schwarz 28 Dec '20

28 Dec '20

Dear all, I am trying to learn how ipip routing works by studying the various setup scripts and wiki pages. Now I came upon a FAQ answer in https://wiki.ampr.org/wiki/FAQ which I do not quite understand: " Can I just route all 44net traffic via a single tunnel? No. The main AMPRNET gateway does not provide this functionality - you must have a tunnel to each system you wish to contact. " Does this mean that I will need to create that many tunnel devices or will a single device be able to handle all the required multiple tunnels? Thank you for considering my question. vy 73 de Roland oe1rsa -- __________________________________________ _ _ | Roland Schwarz |_)(_ | | \__) | mailto:roland.schwarz@blackspace.at ________| http://www.blackspace.at

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net