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
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
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
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
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
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
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
[written by two ARDC Board members kc claffy and John Gilmore]
Along with all the other activities Phil mentioned in his mail, the
ARDC board is talking about RPKI, catalyzed by the mailing list thread
last month. Although John (W0GNU) sent some of his personal thoughts
to the list, he emphasized that he was not communicating a Board position.
As others noted in the thread, it is a complicated issue that admits no
easy solution. There are unknown but presumably small amounts of BGP
hijacking that occur in the wild. (Well, it doesn't matter how small the
amount is if it's your prefix..) Current systems diagnose these mistakes
after they occur; RPKI is an attempt to stop them before they occur.
But it isn't clear to everyone that having that solution, in the political
and litigious economies in which it is embeded, is better than having
the problem it's trying to solve.
Some incorrect assumptions have appeared on this thread, most importantly
regarding the status of the AMPRnet address space, which is, without a
doubt, legacy IP address space. This status has implications for trying
to integrate into an RPKI system that is "rooted" in 5 roots run by RIRs
that don't (always) trust each other. The idea of establishing a new
independent RPKI Trust Anchor is -- as Job points out -- not something
that has much precedent. A comparison to the web's PKI does not lend
confidence in the trustworthiness of the ecosystem. Any organization
that operated a new Trust Anchor would also be subject to tremendous
liability. ARIN's response to that is tremendous indemnification (denying
its RPKI users the right to successfully sue them), even in a hypothetical
situation when ARIN were judged to be clearly at fault. This self-defensive
behavior, plus some policy problems, are limiting RPKI uptake in the
ARIN region. (For data geeks: https://rpki-monitor.antd.nist.gov/ )
Further complicating the issue, ARIN and the other RIRs decided to use
routing certification as a wedge to require legacy users to sign contracts
that both financially support the RIRs (maintaining high integrity
databases is not cheap), and increase the RIRs' control over the legacy
users' address space. At a deeper level, we recognize the architectural
(not to mention sociopolitical) concerns John raised regarding inserting
centralized cryptographic chokepoint(s) into the truly distributed BGP
protocol. Questions we have heard in the debate, which we assume many
amateur radio operators are sympathetic to, include: Who'll watch the
watchers when they control the ability to block or allow users to be
part of the routable Internet? And who will be able to effectively
protest the RIRs' mistakes or overreaches when they can forcibly take
anyone who disagrees with them off the Internet?
We recognize the importance, magnitude, and sociotechnical depth of the
problem. We admit that at this time we do not see a clear path forward
that the whole AMPRnet community would stand behind. Since our mission
is focused on network research, experimentation, and education, we would
welcome one or more serious proposals in the area of BGP routing security.
Approaches that do not require a hierarchical root of trust would be
most consistent with the nature of our mission and the distributed nature
of the Internet. Solutions that expose ARDC to the liability that ARIN
has tried so diligently to avoid are much less likely to be adopted. We
are also aware that routing security is a decades-old problem, and IETF
working groups have argued over solutions for many years without resolution.
We understand that RPKI as currently deployed is a compromise that has
grown out of this history of tension and debate.
Besides trying to solve the routing security problem for the world, we
would also welcome ideas about merely solving it for 44net. If someone
(or two) is inclined to (co)chair a working group on this topic, we could
support workshops (virtual for now) to discuss AMPRnet-specific measures.
https://www.ampr.org/giving/
kc and jg,
on behalf of ARDC Board
