44net

44net@mailman.ampr.org

3179 discussions

Re: [44net] Say hello to Rosy Wolfe, ARDC's new Executive Director

by Paul Sladen

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 28 Aug 2020, Phil Karn wrote: > On 8/27/20 5:12 AM, Paul Sladen wrote: Hello Phil, > point is taken. Excellent. Glad that was useful; hopefully the rest is useful too. > > * page 2, > > http://rct.doj.ca.gov/Verification/Web/Download.aspx?saveas=Founding+Docume… > This document is out of date. > ... > As you can see, the purposes of the foundation were broadened ... QED. Metamorphosis has occurred; and further metamorphosis is planned in 2021: https://www.ampr.org/amprnet/ ] (Now that we are receiving significant investment income from our ] address sale, in 2021 we will transition to a private grant-making ] foundation required to disburse at least 5% of our total assets each ] year, on average.) (Please be very, Very, careful with the wording "total assets"...) ...However, the founding document from 2011 is still /the/ founding document, which enabled charitable incorporation, and immutable, and so still to remind incoming employees/trustees of (p.5): ] All assets of this corporation are irrevocably dedicated to public ] and charitable purposes and no part of the net income or assets of ] this corporation shall ever inure to the benefit of any director, ] officer or member thereof or to the benefit of any private person. Which brings us back to the "assets of this corporation"; > > (ADRC is custodian of US$0.25+ Billion in tangible +non-tangibles). > We will be able to talk about the actual numbers as soon as ... Tangible numbers are unncessary for discussion of the quarter-billion, which is obtainable purely from remaining intangibles (unsold IPs): * US$0.25+ Billion == nominal book value of the remaining IPs (intangible assets) held by ADRC: ($20 * ~12.58 million) ...accounting for retained IPs in the "total assets" appears to be a necessary condition, to have allowed made the declaration that the sale of ~25% of total assets was "insubstantial". (p.1): https://www.ampr.org/wp-content/uploads/Courtesy-Notice-to-AG-Signed-ARDC.p… ] the Sale represents only about one-quarter of ARDC's IP Addresses ] and is therefore not a sale of substantially all of ARDC's ] assets. and thusly fall under the s.5913 non-prior-notification exception: ] Accordingly, advance written notice of this Sale was not ] required under California Nonprofit Public Benefit Corporation Law ] Section 5913. So putting together (1) the 5% disbursement plans for 2021, and (2) the necessity to account for "total assets" to claim the non-prior notification in 2019, ...: There would shortfall after 5 years, because... disbursing 5% of ~0.3 billion total assets (tangible + intangible) = US$15 million/year outgoing (cash); against investment income of say ~10% of that. Result would be ARDC, Inc. returning to being non-liquid c.2025, ...necessitating a further sale of AMPRNet IPv4 addresses. > Until then we are not contractually allowed to disclose But, the Trustees would presumably be completely free to give an update on the planned relationship with CAIDA (UCSD Network Telescope), and long-term sustainable plans for AmprGW? -Paul TL;DR: Be very, Very careful of the 5% total assets idea. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFfSRSdc444tukM+iQRAjv1AJ44Rwblo1HStD+pRTawuoeHYvuDIgCdHRtR WaquVeRqmuymtjxm/Q8sUMc= =uvsx -----END PGP SIGNATURE-----

4 years, 8 months

Say hello to Rosy Wolfe, ARDC's new Executive Director

by Phil Karn

Hello 44net, I'd like to announce that ARDC now has an Executive Director: Rosy Wolfe. She becomes ARDC's second paid employee. We initially looked for people near San Diego where fellow board member KC Claffy and I reside. Rosy, who lives in Portland, OR, came highly recommended by Board Member John Gilmore, and we discovered his instincts were good. She has hit the ground running, providing not just considerable help and support to the Board and Grant Advisory committees, but also some very useful insights from her own experiences as we figure out how to attract a new and more diverse generation not just to ham radio, but to (digital) communications and to STEM (Science, Technology, Engineering and Math) fields more broadly. This bears some emphasis: we see ARDC as not being just about ham radio, or even just about ham radio and the Internet. Ham radio is fun, but it's also a powerful tool for public service and above all, education. And we define "education" very broadly. It goes far beyond formal classroom instruction to group projects to the kind of self-motivated, individual hands-on tinkering and learning-by-doing that is the essence of ham radio. We want to bring that to as many people as possible. We know this isn't going to be easy, so we're going to need a lot of new ideas to fund. We expect many will fail, but that's OK as long as a few really succeed. Rosy definitely understands what we're trying to do. After getting her MS in Digital Media in 2011 at Georgia Tech, Rosy worked at the intersection of technology, activism, art, and design for nearly a decade. In that time (and under her birth name, Beth Schechter), she co-founded and ran an international open source map making community and worked with John Gilmore at an organization supporting open scientific data exchange in cannabis research. Through this work, Rosy has written curricula on basic HTML, CSS, JavaScript, and open source map making, drafted diagrams and educational content on design, science and regulations, the patent system, and more. She has also managed many projects, from data visualizations to installations at Burning Man. She doesn't have her ham license yet, but hey, nobody's perfect... Nevertheless, we are happy to have Rosy's experience in nonprofit administration, project management, and technical education as we move from being a small charity to a large grant-making foundation. Her email address is rosy(a)ampr.org Please join us in welcoming Rosy! And I'll let her introduce herself. 73, Phil Hello 44net! And many thanks to Phil for the kind introduction. I'm thrilled to be here and to finally e-meet all of you. I'm also incredibly excited to be working with ARDC - the organization has an opportunity to do tremendous good in the world, and it's an honor to be selected to help shepherd the process. In addition to supporting grant making for the many innovative initiatives listed on our Grant making Goals page, I'm particularly excited to support emergency communications preparedness, remote deployments, STEM, and generally expanding the demographics of amateur radio and digital communications. Speaking of communications, a key part of my role is to help increase communication and transparency between the Board and this list. To that end, and particularly as we get into administrative flow, please expect updates and reports from me. On the flip side, if you have any questions that I can answer, please don't hesitate to reach out, either on this list or by email: rosy(a)ampr.org. Like Phil mentioned, I don't have my ham license yet, but I'm happy to report that I'm studying for it. In addition to learning more about the radio spectrum, antennae, and repeaters in the coming months, I'm also looking forward to learning about this international community and the many people who are a part of it. If there are community resources or organizations you think I need to know about, I invite you to share them with me. In the meantime, thank you, again, for the warm welcome. Here's to the future of amateur radio and digital communications. Sincerely, Rosy

4 years, 8 months

POS for AMPR router configuration?

by Assi Friedman

Hi: Who took over Brian's role maintaining the router? I need implement a change that was done outside the portal's options. Thanks, Assi kk7kx

4 years, 9 months

Hello, I could use some help recovering my password to the portal

by Muriithi Njeru

In registered as M700KE, if you could help me retrieve my password to the portal the password recovery process is not completing sending email to my email address. Thankyou, Regards.

4 years, 9 months

AMPRNet VPN TLS Error

by Chris Brougham

Hi List, I'm trying to setup the VPN using my LotW cert and followed the instructions on the Wiki for Windows. There was a security issue at first but I added the tls-cipher "DEFAULT:@SECLEVEL=0" line in the .ovpn file and made some progress until I got this: Wed Jul 22 20:14:59 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Searching the archives here I've tried a few things such as editing the authorities file to show the last block only as was suggested by another list member. I also edited the authorities file to show the first block only, but to no avail. Now the user and authorities certs are concatenated as per the WIki instructions, so it's all stock. Any tips for further investigation? 73 Chris VE7YSF aka VA7CAB

4 years, 9 months

Routing Help (linux/ubuntu)

by Ian Redden

Hi Everyone! I have a Ubuntu 20.04 LTS box installed with the following network configuration: *Internet/ISP* ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 209.249.157.70 netmask 255.255.255.248 broadcast 209.249.157.71 inet6 fe80::250:56ff:feb7:eeb6 prefixlen 64 scopeid 0x20<link> ether 00:50:56:b7:ee:b6 txqueuelen 1000 (Ethernet) RX packets 7916 bytes 544678 (544.6 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 975 bytes 184556 (184.5 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 *HAM Network* ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 44.135.100.10 netmask 255.255.255.248 broadcast 44.135.100.15 inet6 fe80::250:56ff:feb7:57ba prefixlen 64 scopeid 0x20<link> ether 00:50:56:b7:57:ba txqueuelen 1000 (Ethernet) RX packets 35 bytes 2558 (2.5 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 37 bytes 3152 (3.1 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 104 bytes 8024 (8.0 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 104 bytes 8024 (8.0 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 *AMPRNet IPIP* tunl0: flags=4289<UP,RUNNING,NOARP,MULTICAST> mtu 1480 inet 44.135.100.9 netmask 255.255.255.255 tunnel txqueuelen 1000 (IPIP Tunnel) RX packets 37 bytes 17484 (17.4 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 5 bytes 260 (260.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Machines on my "ham" network (44.135.100.8/29 - interface ens192) can only communicate within the routes I receive via rip44. Is this normal? For example, from a machine on the ham network (ens192), I can connect to va3emt-1.ampr.org (44.135.87.1) but cannot ping 8.8.8.8 (google dns). A tcpdump shows its going out the wrong interface (ens160). Also, from my ISP, I can ping 44.135.87.1 (and retrieve the web page) but I cannot ping or access 44.135.100.9,10,11,etc .... Here are my commands I'm using to connect: ip tunnel add tunl0 mode ipip local 209.249.157.70 ttl 255 ip link set dev tunl0 up ifconfig tunl0 up 44.135.100.9 netmask 255.255.255.255 multicast ip rule add to 44.0.0.0/9 table 44 priority 44 ip rule add to 44.128.0.0/10 table 44 priority 44 ip rule add from 44.135.100.8/29 table 44 priority 45 ip route add default dev tunl0 via 169.228.34.84 onlink table 44 ip route add 44.135.100.8/29 dev ens192 table 44 /usr/sbin/ampr-ripd -s -r -t 44 -i tunl0 -a 44.135.100.8/29 -d -v Any ideas? Ian. Some debug: root@ampr-router:~# ip rule 0: from all lookup local 44: from all to 44.0.0.0/9 lookup 44 44: from all to 44.128.0.0/10 lookup 44 45: from 44.135.100.8/29 lookup 44 32766: from all lookup main 32767: from all lookup default root@ampr-router:~# ip route show default via 209.249.157.65 dev ens160 proto static 44.135.100.8/29 dev ens192 proto kernel scope link src 44.135.100.10 209.249.157.64/29 dev ens160 proto kernel scope link src 209.249.157.70 root@ampr-router:~# ip route show table 44 | more default via 169.228.34.84 dev tunl0 onlink 44.0.0.1 via 169.228.34.84 dev tunl0 proto 44 onlink window 840 44.2.0.1 via 191.183.136.1 dev tunl0 proto 44 onlink window 840 44.2.0.2 via 98.20.210.138 dev tunl0 proto 44 onlink window 840 44.2.0.3 via 36.83.94.245 dev tunl0 proto 44 onlink window 840 44.2.2.0/24 via 216.218.207.198 dev tunl0 proto 44 onlink window 840 44.2.7.0/30 via 73.116.117.178 dev tunl0 proto 44 onlink window 840 44.2.10.0/29 via 104.49.12.130 dev tunl0 proto 44 onlink window 840 44.2.11.8/29 via 47.33.29.119 dev tunl0 proto 44 onlink window 840 44.2.50.0/29 via 50.63.202.93 dev tunl0 proto 44 onlink window 840 44.4.0.48/28 via 107.3.166.19 dev tunl0 proto 44 onlink window 840 44.4.2.152/29 via 173.167.109.217 dev tunl0 proto 44 onlink window 840 ..... alot of routes here ..... 44.185.66.0/24 via 89.106.108.151 dev tunl0 proto 44 onlink window 840 44.185.69.0/24 via 80.80.140.38 dev tunl0 proto 44 onlink window 840 44.185.80.0/24 via 213.91.190.32 dev tunl0 proto 44 onlink window 840 44.185.92.0/24 via 213.91.190.32 dev tunl0 proto 44 onlink window 840 44.185.96.0/24 via 213.91.190.32 dev tunl0 proto 44 onlink window 840 44.185.103.0/24 via 89.190.200.249 dev tunl0 proto 44 onlink window 840 44.185.104.0/24 via 178.254.198.205 dev tunl0 proto 44 onlink window 840 44.185.105.0/24 via 91.139.210.119 dev tunl0 proto 44 onlink window 840 44.185.106.0/24 via 95.158.166.222 dev tunl0 proto 44 onlink window 840 44.185.107.0/24 via 77.70.122.201 dev tunl0 proto 44 onlink window 840 44.185.108.0/27 via 78.83.56.107 dev tunl0 proto 44 onlink window 840 44.185.109.0/24 via 91.92.93.15 dev tunl0 proto 44 onlink window 840 44.188.1.1 via 70.80.196.6 dev tunl0 proto 44 onlink window 840 44.188.192.222 via 176.67.24.190 dev tunl0 proto 44 onlink window 840 44.224.0.0/15 via 141.75.245.225 dev tunl0 proto 44 onlink window 840

4 years, 9 months

Trying to reach N2NOV

by G1FEF

If anyone is able to contact Charles - N2NOV please could they advise him that emails to his @n2nov.net address is bouncing. Please ask him to get in touch with me: <n2nov(a)n2nov.net <mailto:n2nov@n2nov.net>>: host mx.spamexperts.com <http://mx.spamexperts.com/>[130.117.53.188] said: 550 Your country is not allowed to connect to this server. (in reply to RCPT TO command) Thanks, Chris - G1FEF

4 years, 9 months

My view to 44net's future

by Clive Blackledge

cc: 44ngn Greetings 44net, KF6DMA checking in. Thank you for letting me join the group. I’ve been licensed since 1996 or so, but I’ve rarely spent time on the air talking. Instead, the internet seemed much more my speed at 2400 baud at the time. There seemed to be a rather insurmountable generational gap when I started, but that has become narrower as the years progressed. I now have my own health ailments I can talk about in detail. :) I’ve been into packet radio and played with radio meshes, but a majority of my time was spent on the internet. My assortment of jobs I’ve held since high school have all prepared me for the job I have today working as a systems engineer for a large company, and I love it. I bring this up, as I was reading the archives to see the challenges with AMPRnet and ARDC in general, and thought I’d throw in my 2c from an outsiders systems engineering view (although hopefully not an outsider for too long). >From the surface, it seems like AMPRnet needs a ‘one country, two systems’ approach. An external system that interfaces with the public internet and deals with the trends there (RPKI, Domain keys, firewalls, etc.) and another that the ham community prefers (open, encryption-free communication). The two are pretty much at odds with each other, especially now ‘ssl everywhere’ has become a thing on the internet. Bridging both systems becomes difficult, but not impossible. What I propose is getting the internet-side figured out first. Initially I would see what it would take to get a .ham TLD. With that, we can run our own DNS registry, free to anybody licensed. It could include DNSSEC, and possibly our own internal trust registry, maybe working with LOTW to expand how they use PKI and certificate management. Next I’d look to see how we can give address space to communities that need it without requiring BGP. It seems people fall into various buckets when it comes to requesting address space here. Some use cases that I can think of: • Static IPs for services accessed via the internet like echolink, IRLP, etc. • Provide amateur services with multiple ISPs address space to announce • Bridge unencrypted services between the internet and something like broadband hamnet, etc. One challenge is announcing 44net space on the internet when filtering becomes more common and LoAs aren’t enough anymore. The use of tunnels today bridges this gap, but it doesn’t scale very well. My proposal is to look into datacenter space in some of the major IXs (not just UCSD) today and announce large chunks of 44net far and wide. The anticipation is to get grandfathered to avoid filtering that is likely to happen increasingly in the coming years. Hopefully the nonprofit status of ARDC can get us some goodwill/discounts with network operators and datacenters, but it’s like finding the perfect repeater location… it will still cost money for hardware and rent, even with the most generous landlord. For those who wish to use BGP, that’s still an option. I would recommend most people join an overlay network (sd-wan) solution that can provide the same benefits of BGP (multiple paths, static IPs, etc) but is easy enough to assign IP blocks and route IPs without BGP. Some solutions today that are open source and create a managed VPN mesh that can be managed from a centralized location. It’s like IP-IP tunneling used today, except it abstracts away the need for a static IP tunnel endpoint, and auto-routes away from links that have bad connectivity. Using an SD-WAN also provides the ability to do malware checking, firewalling, and other features that would be normal in a network like this. People can choose if nodes can only talk to other 44net nodes or expand access to the internet as a whole. Once the internet side is sorted out, the “internal” side of 44net could implement open services for everyone, including packet gateways, DNS, etc. The anticipation is to be able to access these services without needing to leave 44net. This affords us a few things. For example, replication of the .ham TLD I mentioned above can potentially be updated over RF, so everyone can have a copy of the complete DNS zone. The idea here is while we do invest heavily on the internet side, we also invest in the ability to run 44net without the internet. By using inherent multicast abilities of RF, plus anycast, we have our own replicated decentralized internet-free DNS infrastructure. For things like mail, winlink has had a head start here. We may need to borrow a lot of technology used here or invent our own. Satellites are getting cheaper to provide IP-based communication and they have potential to avoid terrestrial internet. Could we partner with Space-X Starlink? With an overlay network, packets can go satellite, internet, cellular, or all three. >From there, the rest of services can fall in line as needed. Need a replicated wiki knowledgebase? Done. Near-time speed chat? Sure. APRS gateway without the internet? Yup. Partner with AREDN to mesh the meshes more securely and redundantly? It's possible. We can become the ISP for amateur radio and create our own walled garden while also interfacing with the wild west of the internet to protect our interests there. -Clive KF6DMA

4 years, 9 months

Re: [44net] My view to 44net's future

by Rob Janssen

It is about a year ago that I tried to discuss such a proposal. My view was like this: let's establish routers at datacenters around the world, in addition to the existing UCSD router and some others that already handle /16 networks on internet. I was thinking about around 10 routers globally. They interconnect using BGP on private AS numbers (the 32-bit AS numbering scheme we already use) over a mesh of tunnels between them, to exchange routing information for 44Net subnets, but on internet the announcing remains as it is (i.e. the whole network is announced at UCSD, and regional subnets are, but do not need to be, announced at those global routers). The "users" connect to those routers using a (small) variety of tunnel protocols to match the restrictions they face from their internet providers, e.g. forcibly being behind a NAT router, having a dynamic IP address, maybe having some enforced firewalling, etc. I was thinking of standard tunneling protocols like GRE, GRE/IPsec, L2TP/IPsec, etc. The tunnels would be operated in a point-to-point fashion by default (/30 or /31 subnets on the tunnel), and the users would use BGP to announce their own routable subnet over that. They can setup redundant tunnels to multiple global routers when they desire to do so. They can also setup tunnels directly to other users when desired, and run a BGP session with them. And of course, radio links can be incorporated in the scheme. Users could use the widely available inexpensive routers available today that can use these standard protocols without special tinkering with scripting, locally compiled executables, etc. E.g. the inexpensive models available from MikroTik, Ubiquiti, etc. More technically inclined users could install software on their own Linux system or -board. I see this as a solution for the following problems: - more and more users struggle with getting IPIP routed on their internet connection, due to them being behind ISP-managed routers, CGNAT, having dynamic addresses, etc. - non-technical users struggle to get our special IPIP mesh operational on their routers, where using industry-standard protocols would be much easier as their router config interface already knows about those. - some users requested to have redundant IPIP tunnels (multiple internet routers serving the same 44Net subnet(s) in a redundant way, which the IPIP mesh cannot do. - the IPIP mesh does not really allow to check the status of the configured gateway routers, so routers that have not been operational for a long time just remain in the tables. I expected enthousiasm from the users, but unfortunately I was met with a lot of resistance to change, e.g. from people who believed that such a system would rob them from their direct tunnel to their buddies on the other side of the world and force them to go via established and centrally managed hubs (incorrect, of course). As I see this as a hobby and not as a struggle to be right and convince those that do not want to be convinced, I did not pursue it further. I don't know if the attitude an scepticism has gone away now. We would have to see in a new discussion. Maybe some of the opponents have realized by now that it would be better to have a more flexible mechanism like this instead of going on with the IPIP mesh forever. Maybe not. I don's see the need of routing the entire 44Net from internet to all those routers. When everyone routes only their own regional subnet(s), it remains more manageble and we do not face the raised issues. Furthermore, some of us have our ISP announce the relevant regional subnet on their redundant border routers under their AS, and then route it to our "gateway" router. That relieves us from being responsible for that announcement, and we use the ISP NOC services. But of course it also means we are less integrated with the internet routing, e.g. we cannot allow that subnets from our announcement are routed to others. Of course everyone can decide if they want to announce their subnet on internet directly or via an ISP, but I would suggest that the internet side of things be kept separate from our internal routing (2 BGP instances, the 44Net one using a private AS number) W.r.t. the .ham TLD: I don't see what advantage that would bring, we already have the .ampr.org domain and we run the DNS for it. It should offer the same capabilities as a dedicated TLD, I think, at a much lower cost. Rob

4 years, 9 months

Update on ARDC Board activities

by Phil Karn

I want to provide an update on what ARDC's nonprofit board has been doing since Brian's sudden passing last November. Our three priorities have been: 1) Sustainability and continuity of the AMPRnet infrastructure. As I reported to the list 30 Dec 2019, Chris Smith, G1FEF (chris(a)g1fef.co.uk) has taken over AMPRnet portal management among other sysadmin tasks. Chris is now working under paid contract with ARDC, rather than as a volunteer. Besides keeping the infrastructure going, he is also dedicating some paid time to improving the Portal and other software. The process of contracting made us aware that we had never adopted a GDPR-compliant privacy policy, so we've engaged lawyers to write one -- as simple as they'll let us make it, given that we do actually keep personal data about hams who apply for net44 allocations, write for the mailing list or wiki, etc. Actually following this policy then requires us to make staff policies to match it (Record Retention and Data Destruction, Data Custodianship and Access), plus a Terms of Use for the website, which we are still actively trying to shorten and simplify. (I hate this legal stuff as much as anybody, but it has to be done.) 2) Gathering administrative, financial and legal records, investing our funds responsibly, and preparing for our first financial audit. Brian was a meticulous record-keeper, and we do have all his records, but clearly he had no intention of passing so soon. So this was not trivial. The audited financials and our 2019 tax return will be published on the website and announced on the mailing list. 3) Establishing processes for accepting and reviewing grant applications, awarding grants and following up on how our grants are spent. We are steadily adding process and documentation. The board appointed five volunteers to the Grants Advisory Committee for 2020 and it's up and running. They meet (virtually) every two weeks to review, discuss and evaluate the proposals that are now flowing in. The Committee (and the Board) do approve a few grants as originally submitted, but most involve some negotiation. Typically we'll ask an applicant to divide a single request into well-defined sub-projects, each with a clear objective and cost. Although ARDC did fully fund the UCSD Turing Memorial Scholarship in Brian's memory, in general we want to avoid funding other organizations' endowments. So we'll ask applicants to request only what they can usefully spend in one year, and come back next year for more. Then we can see what they've accomplished as we decide whether to grant more. For more information, see: https://www.ampr.org/giving/ Here is a list of all grants made. They total more than a million US dollars so far. https://www.ampr.org/grants/ As the Giving page describes, there is a lot more to do. We hope to increase the pace this year, but we are trying hard to get everything right, or at least not terribly wrong. I never expected to become ARDC President. Brian was a close personal friend and you can't believe how much I wish he still had this job. I have health problems of my own slowing me down, and while I've avoided Covid (so far) the pandemic certainly isn't helping. My original plans to promote ARDC at major ham gatherings like Dayton and Friedrichshafen evaporated months ago. But the entire Board remains committed to realize Brian's vision and honor his long commitment to the AMPRnet infrastructure and community, and to the Internet community. Brian stood at the intersection of both, and ARDC will continue to do the same. 73, Phil Karn, KA9Q ARDC President

4 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net