44net December 2020

44net@mailman.ampr.org

45 participants
33 discussions

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

AMPR / HAMNET Spain?
by Volker Kerkhoff 25 Dec '20

25 Dec '20

Hello, AMPR / HAMNET Spain seems to be defunct... No active radio nodes anywhere, last update on website https://hamnetspain.wordpress.com/ is from 1 year ago... Our national and local ham radio associations seem to be quite uninterested and indifferent to AMPR as well. IF the current co-ordinators for Spain are impeeded, gone or overworked, well, I would love to jump in. I am an IT engineer, have some time and some resources and and I would be glad to assist and help with any tasks, and also do some advocacy for AMPR / HAMNET with local fellow OMs and the local and national associations. I have really great internet at home (1Gb symmetric fiber) and could initially give VPN access to quite some hams unable to connect via radio. Any suggestions, requests or pointers are welcome! 73 de EA7KLK, Volker

1 0

Re: [44net] JNOS and IP forwarding?
by Chris Maness 22 Dec '20

22 Dec '20

I am trying to create a local LAN, and I can get it to work in pure Linux using 9k6 modems and kissattach. However, it does not seem that JNOS is allowing forwarding or IP access. It also looks like the help ip info may be depreciated because I tried the examples allowing access, and they did not seem to work. Any hints would be appreciated. 73 de KQ6UP On Tue, Dec 22, 2020 at 12:10 PM Stuart Longland <stuartl(a)longlandclan.id.au> wrote: > > kq6up, > > On 23/12/20 5:56 am, kq6up via 44Net wrote: > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net > > > > Your email message got lost, the above quoted section is all I received > this end, maybe try sending the email unsigned to see if the mailing > list software is stripping your message body by mistake. > > Regards, > -- > Stuart Longland (aka Redhatter, VK4MSL) > > I haven't lost my mind... > ...it's backed up on a tape somewhere.

1 0

JNOS and IP forwarding?
by chris＠chrismaness.com 22 Dec '20

22 Dec '20

1 0

Anyone running Linux Kernel 5.4.* using on 44-net (or Raspberry Pi)?
by Chris Maness 18 Dec '20

18 Dec '20

I am having a major headache trying to get my encap tunnels going. Old commands don't seem to work correctly. I can make single tun* devices for each IPIP route and they work, but I know I should be able to add routes to tunl0 device and have them all encapsulated when I use the gw flag in routes add command. This is not working on the Raspberry Pi. -Chris KQ6UP

3 4

ARDC now accepting applications for Technical and Grants Advisory Committees - due Jan. 7, 2021
by Rosy Wolfe 17 Dec '20

17 Dec '20

Hello 44net, In addition to welcoming new board members - Keith Packard (KD7SQG) and Bob McGwier (N4HY) - ARDC is now welcoming applications for 2021 Technical and Grants Advisory Committee members. **Grants Advisory Committee (GAC)** The job of the GAC is to review and provide advice to the Board regarding inbound grant proposals and other grantmaking opportunities. In 2021, ARDC is looking to process likely hundreds of grant applications for quality projects. The job of the GAC is to review and provide feedback on eligible proposals. **Technical Advisory Committee (TAC)** The Technical Advisory Committee (TAC) plans and executes improvements in the 44net technology, architecture, and policy. In 2021, some of the TAC's primary goals will be: * oversee a complete rewrite of the Portal * improve address allocation policies and responsiveness * investigate and instigate next steps toward making IPv6 usable in the Amateur Radio service * investigate options for RPKI or other automated subnet verifications **How to Apply** If you are interested in joining either of these committees, please send a resume and brief cover letter to contact(a)ampr.org by Thursday, Jan. 7, with the name of the committee you'd like to join in the subject line. We'll review all applications and seek to make a determination by Friday, Jan. 29. * These committees meet twice a month for at least an hour. There is also email correspondence and reviews that happen between meetings. Estimated level of effort (LOE) is about 2-3 hours/week. * The term for each of these is a year. For more information about the roles and duties of these committees, you can read the Advisory Committee Policy in full here: https://www.ampr.org/advisory-committee-policy/ Feel free to ask any questions here on 44net or email us at contact(a)ampr.org. We're looking forward to seeing your application! All the best, Rosy -- Rosy Wolfe - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net December 2020