44net

44net@mailman.ampr.org

3196 discussions

IPIP mesh with VyOS on Vultr
by John Burwell 30 Dec '21

30 Dec '21

I am attempting to get connected from VyOS, and I seem to have several pieces in place, but I am not able to ping any hosts across any IPIP tunnels. I can ping amprgw.ucsd.edu across the public Internet. I have configured a `tun44` interface. I have ampr-ripd running, and it receives updates every five minutes. The resulting routes appear in my routing table, and if I do `ip route get` on 44-net hosts, it shows them routing through my `tun44` interface. But if I try to ping 44-net hosts or access them at all, I get timeouts. What might I be missing? My gateway public IP is 155.138.247.113. My allocated subnet is 44.31.64.1/27. I created a firewall group named ALLOW-ALL with a default rule set to 'accept' just to rule that out for troubleshooting. Tunnel interface configuration: tunnel tun44 { > address 44.31.64.1/32 > description AMPRNET > disable-link-detect > encapsulation ipip > firewall { > in { > name ALLOW-ALL > } > local { > name ALLOW-ALL > } > out { > name ALLOW-ALL > } > } > mtu 1450 > multicast enable > remote 0.0.0.0 > source-address 155.138.247.113 > } ampr-ripd startup output: root@vyos:/home/vyos# ampr-ripd -svd -i tun44 > Using metric 0 for routes. > Using TCP window 840 for routes. > Using routing table 'main' (254). > Loaded 738 entries from /var/lib/ampr-ripd/encap.txt > Max list size: 1000 entries > Detected tunnel interface address: 44.31.64.1 > Interface detected: lo, IP: 127.0.0.1 > Interface detected: eth0, IP: 155.138.247.113 > Interface detected: tunl0, IP: 0.0.0.0 > Interface detected: tun44, IP: 44.31.64.1 > Assigned tunnel interface index: 5 > Local IPs: > 127.0.0.1 > 155.138.247.113 > 44.31.64.1 > Using gateway 155.138.246.1 for direct 44net endpoints via interface eth0. > Setting routes (738). > Creating multicast RIP UDP listening socket. > Setting up multicast interface. > Waiting for RIPv2 broadcasts... > Broadcasts eventually start appearing. Before I run ampr-ripd, here's the route I get for 44.0.0.1 — over the public Internet: 44.0.0.1 via 155.138.246.1 dev eth0 src 155.138.247.113 uid 0 And I can ping 44.0.0.1 in this state. After I run ampr-ripd, here's the route to 44.0.0.1 — over the tunnel: 44.0.0.1 via 169.228.34.84 dev tun44 src 44.31.64.1 uid 1003 And I can no longer ping 44.0.0.1 — it just times out: vyos@vyos:~$ ping 44.0.0.1 interface tun44 > PING 44.0.0.1 (44.0.0.1) from 44.31.64.1 tun44: 56(84) bytes of data. > ^C > --- 44.0.0.1 ping statistics --- > 4 packets transmitted, 0 received, 100% packet loss, time 88ms This is all on VyOS 1.3 equuleus (Debian buster), hosted at Vultr. Any ideas, or other troubleshooting suggestions? Thanks very much!

1 1

Request for official clarification from ampr.net BOD
by Kevin Walsh 17 Dec '21

17 Dec '21

It would be most helpful if the amprnet BOD could post in writing an official statement regarding using common secure communications (https. TLS etc.) over the 44. IP network. This email list is used for communications regarding the use of the IP address space. I'm not asking about the use of encryption over part 97 RF radio, just the 44 network IP address space. I am not aware of any portion of the Part 97 rules that apply to the wired internet at large. Everyone has an opinion, but it's time for the amprnet Board to clarify the muddy waters around the use of the amprnet IP space and publish those rules. Please! 73, Kevin Walsh W8KHW

13 13

Re: [44net] DN42 for 44net?
by John Burwell 04 Dec '21

04 Dec '21

> > Thanks for sharing. I see this has been around a while, but I hadn’t run into it myself yet. Apple is currently doing something like this with IPSEC and IPv6 for iCloud users; pretty much any iCloud user is always on a private VPN with all their other iCloud devices. And there are commercial enterprise SD-WAN products and cloud providers that offer a similar approach for SMBs and branch offices. Azure and AWS offer almost exactly this between virtual networks, data centers, and regions, down to the private ASNs. It’s nice to see a project built on open standards for the express purpose of playing with it and learning about it. Seems very much like something 44net could benefit from studying carefully. From: KUN LIN <dnwk(a)linkun.info> > To: "44net(a)mailman.ampr.org" <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Thu, 2 Dec 2021 18:48:49 +0000 > Subject: [44net] DN42 for 44net? > > > https://dn42.dev/Home > > Just discover this new thing where it will create mesh networks and even > BGP via VPN tunnels. This maybe an interesting way for 44net to considering > implement. > > dn42 is a big dynamic VPN< > https://en.wikipedia.org/wiki/Virtual_private_network>, which employs > Internet technologies (BGP<https://en.wikipedia.org/wiki/Bgp>, whois > database, DNS<https://en.wikipedia.org/wiki/Domain_Name_System>, etc). > Participants connect to each other using network tunnels (GRE< > https://dn42.dev/howto/GRE-on-FreeBSD>, OpenVPN< > https://dn42.dev/howto/openvpn>, WireGuard< > https://dn42.dev/howto/wireguard>, Tinc<https://dn42.dev/howto/tinc>, > IPsec<https://dn42.dev/howto/IPsec-with-PublicKeys>) and exchange routes > thanks to the Border Gateway Protocol. Network addresses are assigned in > the 172.20.0.0/14 range and private AS numbers are used (see registry< > https://dn42.dev/services/Whois>) as well as IPv6 addresses from the > ULA-Range (fd00::/8) – > > >

15 35

DN42 for 44net?
by KUN LIN 02 Dec '21

02 Dec '21

https://dn42.dev/Home Just discover this new thing where it will create mesh networks and even BGP via VPN tunnels. This maybe an interesting way for 44net to considering implement. dn42 is a big dynamic VPN<https://en.wikipedia.org/wiki/Virtual_private_network>, which employs Internet technologies (BGP<https://en.wikipedia.org/wiki/Bgp>, whois database, DNS<https://en.wikipedia.org/wiki/Domain_Name_System>, etc). Participants connect to each other using network tunnels (GRE<https://dn42.dev/howto/GRE-on-FreeBSD>, OpenVPN<https://dn42.dev/howto/openvpn>, WireGuard<https://dn42.dev/howto/wireguard>, Tinc<https://dn42.dev/howto/tinc>, IPsec<https://dn42.dev/howto/IPsec-with-PublicKeys>) and exchange routes thanks to the Border Gateway Protocol. Network addresses are assigned in the 172.20.0.0/14 range and private AS numbers are used (see registry<https://dn42.dev/services/Whois>) as well as IPv6 addresses from the ULA-Range (fd00::/8) – Kun

3 3

Additional Services Idea
by Kris Kirby 23 Nov '21

23 Nov '21

Another suggestion I'll make is that beyond support Dynamic DNS for various use cases, to allow end users to manipulate thier own forward and reverse DNS records and tie that functionality in with dynamic DNS. -- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager

1 0

Potential commercial use / TOS violation 44.144.50.0/24
by Jeremy Cooper 22 Nov '21

22 Nov '21

Hi all, I’d like the ARDC to investigate and possibly revoke the assignment for 44.144.50.0/25 due its use for commercial purposes. I’m a long time member of the group here but I’m also heavily involved in the Helium radio-based blockchain. I’ve noticed three Helium “hotspots” or “miners” that are using this allocation. While I am personally a fan of Helium, I don’t think its use is permissible on the AMPRNet as Helium hotspots do earn monetary compensation for being connected to the Internet. As a responsible AMPR block recipient myself, I feel it’s important that we continue to honor the ARDC’s rules for the AMPR space, and this is one of them. The hotspots in question are: * zany-pecan-kitten at 44.144.50.71 (https://explorer.helium.com/hotspots/112en278X7KpSMfgH9JMnEfkfLSsi2osRjJ1mL…) * petite-flint-bird at 44.144.50.73 (https://explorer.helium.com/hotspots/11bkMgWVDYSteuq1fLvowC9z4BVReQrXNGCq4F…) * furry-pine-raccoon at 44.144.50.74 (https://explorer.helium.com/hotspots/112TRAzGUMNvEYEtHawWymZTA4cX9BWu9QFw1v…) Sincerely, Jeremy Cooper (KE6JJJ)

14 31

Re: [44net] Potential commercial use / TOS violation 44.144.50.0/24
by Jeremy Cooper 21 Nov '21

21 Nov '21

> A reply by the ARDC IT director specifically requesting that abuse reports be sent to abuse at ardc.net <https://mailman.ampr.org/mailman/listinfo/44net> <mailto:abuse at ardc.net <https://mailman.ampr.org/mailman/listinfo/44net>> and you decide to double down and list more potentially offending addresses publicly? > > Interesting approach. > > Ian VE7BST Ian, I thought I was in a private conversation with Chris when I had replied. It wasn’t until I had already sent the message that I saw that the entire list was still CC’d. My apologies, but also a modicum of understanding is also deserved, too.

2 1

Staff introduction, Interview invitation, PoP proposal update, TAC & GAC openings, and 990-PF
by Rosy Schechter - KJ7RYV 15 Nov '21

15 Nov '21

Hi, 44net! Writing with a few updates that may interest you. First, I’d like to introduce you to our Administrative Coordinator, Merideth Stroh – KK7BKI. She comes from a family of hams and is helping us with everything administrative. Please join me in welcoming her to the team! In advance of our upcoming board retreat in early December, Meredith and I will be interviewing folks one-on-one about the future of amateur radio and digital communications. If you would like to take part in one of these interviews, you can sign up here: https://calendly.com/ardc-rosy/30min If you want to participate but can’t find a time listed, please reach out and we’ll do our best to find a time that works. Note that we have some times available in early December, but if you want your thoughts brought to the board, please find a time by Dec. 2. If so moved, you are also invited to apply to join either our Technical or Grants Advisory Committees (GAC & TAC). Note that, for 2022, the role of the TAC is going to change a little bit. In addition to focusing on PoP development, we may also call upon TAC members to help evaluate particularly technical in-progress grants. Learn more on our blog here: https://www.ampr.org/now-accepting-applications-for-grants-advisory-committ… Speaking of PoPs, we’ve been working on a plan to develop PoPs for the address space, which incorporates a lot of the feedback and thoughts we’ve heard on this list and through private mails from some of you. When it’s in a better place to share (it’s so close!) I’ll do so. Thanks for your patience on this – we’ve taken in a lot of info and are working with volunteers to review, so it’s not a fast process, but it’s a thorough one. Last but not least, some of you have asked to see our 2020 tax return (IRS Form 990-PF). You can see all our public financial documents here: https://www.ampr.org/about/legal/ Specific links for the 2020 documents are: * Audited financial statements: https://www.ampr.org/wp-content/uploads/Amateur-Radio-Digital-Communication… * 990-PF: https://www.ampr.org/wp-content/uploads/Amateur-Radio-Digital-Communication… Thank you for your patience here as well. As Bdale shared in an earlier mail, with the extra time allotted for filing tax returns, many accountants have been running behind this year, including ours. Here’s hoping that we get this filed earlier next year. As always, please don’t hesitate to reach out with any thoughts and questions. 73, Rosy -- Rosy Schechter - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ampr.org

1 0

Policy around /24 allocations for BGP use
by Donald Gordon 12 Nov '21

12 Nov '21

Hi Does AMPRnet have any policy around allocating /24s to individual hams for the purpose of experimenting with BGP/etc? My local coordinator says this used to be a "yes, but you'd have to be a club not an individual." However I note looking through AMPR allocations there are some in e.g. 44.31 listed as educational/tinkering BGP. Which is what I want to do. Should I be requesting in 44.31 instead of my country's allocation? Regards Donald Gordon (ZL2IP)

10 9

Tunnel setup help: Debian 11
by KUN LIN 12 Nov '21

12 Nov '21

I have been trying to configure the AMPRtunnel for a while without success. Could someone please point me to the right direction. I am running Debian 11 with public IP. I have configured the public IP in the AMPR portal as gateway. I am trying to follow this document https://wiki.ampr.org/wiki/Ubuntu_Linux_Gateway_Example When I try to run find_password.sh in ampr-ripd-2.4, I am stopped at Waiting for RIPv2 broadcasts... and never retrieve a password. Here is what I have done so far. in /etc/network/interfaces, I added auto ens3:1 iface ens3:1 inet static address 44.26.0.168 netmask 255.255.255.248 Then I created ipip tunnel using following commands ip tunnel add ampr0 mode ipip local 209.141.42.9 ttl 255 ip link set dev ampr0 up ifconfig ampr0 multicast ip rule add to 44.0.0.0/8 table 44 priority 44 ip rule add from 44.26.0.168/29 table 44 priority 45 ip route add default dev ampr0 via 169.228.34.84 onlink table 44 ip route add 44.26.0.168/29 dev ens3 table 44 Then, I run ampr-ripd -d -v -i ens3 to get the password in order to plug into lat command ampr-ripd -s -i ampr0 -a 209.141.42.9-t 44 -p <SecretPassword> However, the find_password.sh stopped at waiting for ripv2 broadcast. Here is the logs for command Using metric 0 for routes. Using TCP window 840 for routes. Using gateway 209.141.42.1 for direct 44net endpoints via interface ens3. Waiting for RIPv2 broadcasts... Any idea on what am I doing wrong? Thanks Kun

6 15

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net