- 44net - mailman.ardc.net

Re: [44net] DDWRT Gateway Instructions
by lleachii＠aol.com 09 Sep '20

09 Sep '20

Mike, DD-WRT is not known to provide a method to compile/install the necessary software (i.e. a RIP44 routing daemon). Aside from this, I cannot recall if a tunnel can be established. Nonetheless, if you were to succeed standing up a tunnel, you'd need the routing daemon to properly configure your reply traffic. This routing daemon concern may be overcome by employing a Munge Script (hopefully DD-WRT has some tools like: `curl`, `ftp`, `grep`, `fgrep`, `sed`, `sort` and `diff` installed in the firmware). https://wiki.ampr.org/wiki/Munge_script You can start testing using commands from the startampr, OpenWrt, Ubuntu and/or Linux setup guides on the Wiki. Feel free to ask any questions (when you can stand up a tunnel). I've never used the Munge Script method, I'm sure others have (I should note that there's a script posted that can parse the encap.txt file - it's located on the Firewall page). The `ip tunnel` commands in `startampr` should be of help to test establishing the tunnel. https://wiki.ampr.org/wiki/Startampr#Script --- - Prior to using OpenWrt, I personally forwarded IPENCAP (IP Protocol No. 4) to a gateway running Ubuntu Server. - https://wiki.ampr.org/wiki/Firewalls#DD-WRT - Also see "Static IPENCAP Filtering of AMPR Nodes" here: https://wiki.ampr.org/wiki/Firewalls#iptables 73, - Lynwood KB3VWG

1 0

DDWRT Gateway Instructions
by Mike Swiatkowski 09 Sep '20

09 Sep '20

Does anyone know how to set up an AMPRnet gateway on a router with DDWRT? I don't want to use OPENWRT based on previous experience. Thanks, Mike, AA9VI

1 0

OpenWrt MSS Clamping - 19.07.4
by lleachii＠aol.com 09 Sep '20

09 Sep '20

All, First, welcome to the new Director and thanks for the work Chris! I wanted to inform those with OpenWrt-based nodes that version 19.07.4 should fix an MSS clamping bug that was reported to the developers. Some of you that setup OpenWrt routers have noted to me that MSS seemed problematic in one direction. I've worked around this with other OpenWrt operators by placing MSS clamping on the LAN as well as the tunnel-facing sides of the OpenWrt config. Hopefully 19.07.4 fixes the need for this. https://openwrt.org/releases/19.07/notes-19.07.4#major_bug_fixes 73, - Lynwood KB3VWG

1 0

Portal maintenance
by G1FEF 06 Sep '20

06 Sep '20

The Portal, Wiki & website will be offline for some much needed maintenance for the next hour. Regards, Chris - G1FEF

1 0

ax25ipd setup with socat
by Marius Petrescu 02 Sep '20

02 Sep '20

Since I get questions about how to use the current kernels for axip or axudp tunnel setups, here is my solution for this, using socat: Here is an example for an axip tunnel. First, create a transparent pty pair, lets say axip an kip located in /var/ax25 (names and locations can be chosen freely): /usr/bin/socat pty,link=/var/ax25/axip,raw,echo=0 pty,link=/var/ax25/kip,raw,echo=0 & Next, attach the kernel side to one end and create a ax25 port let say 'aprs' with address 44.128.1.1 and netmask /32: /usr/bin/kissattach -l /var/ax25/kip aprs 44.128.1.1 ifconfig ax0 netmask 255.255.255.255 (ax0 is the first port created by kissattach) Also, configure port 'aprs' in the ax25 daemon and start it... /usr/sbin/ax25d The other end needs to be configured in the ax25ipd daemon config file to use the other end provided by socat: mode tnc (...) device /var/ax25/axip (...) route n0call 44.128.2.3. b (...) I think this will help, Marius, YO2LOJ

1 0

Re: [44net] Say hello to Rosy Wolfe, ARDC's new Executive Director
by Paul Sladen 29 Aug '20

29 Aug '20

-----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-----

3 2

Say hello to Rosy Wolfe, ARDC's new Executive Director
by Phil Karn 28 Aug '20

28 Aug '20

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

2 2

POS for AMPR router configuration?
by Assi Friedman 06 Aug '20

06 Aug '20

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

1 0

Hello, I could use some help recovering my password to the portal
by Muriithi Njeru 05 Aug '20

05 Aug '20

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.

2 1

AMPRNet VPN TLS Error
by Chris Brougham 25 Jul '20

25 Jul '20

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

2 2

Routing Help (linux/ubuntu)
by Ian Redden 22 Jul '20

22 Jul '20

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

2 2

Trying to reach N2NOV
by G1FEF 19 Jul '20

19 Jul '20

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

2 1

My view to 44net's future
by Clive Blackledge 14 Jul '20

14 Jul '20

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

5 6

Re: [44net] My view to 44net's future
by Rob Janssen 14 Jul '20

14 Jul '20

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

10 20

Update on ARDC Board activities
by Phil Karn 03 Jul '20

03 Jul '20

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

2 1

RPKI, BGP security, and possible paths forward
by k claffy 03 Jul '20

03 Jul '20

[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

1 0

TA2T Coordinator for Turkey SK
by G1FEF 29 Jun '20

29 Jun '20

I have been informed of some more sad news: TA2T, the coordinator for Turkey is SK. Baris, TA7W has offered to step up as coordinator, unless anyone else is interested or has any objections? 73, Chris - G1FEF

2 1

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>Email servers for instance need to be on addresses with a reverse DNS >pointing to the same name. To fight a spam, otherwise won't be accepted >by majority of other email servers. >How can we achieve something like this? > mail44.hamradio.si 44.150.0.10 > 44.150.0.10 mail44.hamradio.si That is true, but you do not need to run your mailserver under the hamradio.si domain even when you handle mail for that domain. It would work perfectly fine with a domainname like mail44.s57nk.ampr.org (both forward and reverse) and then in hamradio.si an MX record with that name. For this kind of thing we use "club callsigns" like pi9noz or pi4nos. Rob

1 0

Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

I notice that more and more 44net traffic originates from addresses that are not registered in DNS. To identify an amateur radio transmission, it is required in most countries that the callsign is included in transmissions. Up to now I have considered traffic from a net44 address to be identified by the reverse name that can be looked up in DNS, and that has the basic structure of "hostname.callsign.ampr.org" (with of course some variations, but always the callsign of the responsible station is part of the name). I think everyone should be encouraged (or even required) to register all used addresses in DNS. There may have been some hurdles to do that in the past (e.g. the never completed DNS part of the portal, the unavoidable restrictions of the ampraddr robot to accept only updates from coordinators). Everyone who has e.g. a number of hosts in the 44.190 or other not nationally registered parts of the network can send a list of their IP addresses and corresponding hostnames (with names like the above, i.e. a callsign embedded in them) to me, then I can submit them to the robot and they get registered in the ampr.org main DNS service. Otherwise please register your hosts through your local coordinator, even when you have been allocated an entire subnet. Furthermore, I see that more and more subnets have arranged to delegate DNS to their own servers. I think it would have been better to keep everything in a single list and then run a secondary zone within the own network (we do that here), instead of this split. Maybe a more convenient API for updating the main DNS should be (or would have had to be) added to avoid this? Or are there other reasons for operating this way? Given that we now have this situation, I think there should be a general policy of allowing AXFR and preferably also IXFR zone-transfers of these zones between net44 addresses. We should not have "dark and secret" zones that are inaccessible to others, I think, especially for the reverse (PTR) zones. Rob

11 10

why and Wiki
by Dave Wade 17 Jun '20

17 Jun '20

Folks, Being marooned in that back water that is the UK I wonder what TCPIP packet activity there is in the UK and on what frequencies and how this would be supplemented by using 44net over the internet? I though I would read the Wiki but that seems to be un-availble.. Dave Wade G4UGM & EA7KAE

2 2

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>I'm replying to the main thread, as Rob still insists with posting using his >broken MUA which breaks threading, making it impossible to follow his >ramblings. Thanks Rob. It is not convenient for me either! But I don't want to forward this list as separate mails as sometimes there are frantic discussions about topics that do not interest me at all (like RPKI) and I don't want my mail bell to ring all day (and load amsat.org with forwarding all those messages). So I am subscribed to the digest only, I sometimes watch the archives for quicker responses, and I cannot reply with the proper threading. I think I have mentioned it before: this list should be a newsgroup on an NNTP server. If only to honor Brian Kantor. Accessing it via a usenet news reader would be so much more convenient, you can just read it when you like and kill uninteresting threads. Or otherwise just use a forum. >Having reverse DNS with a callsign in it doesn't meet identification >requirements in the ITU or FCC rules, assuming the packet is traversing an RF >link on amateur frequencies. Under FCC rules (and I'm aware you may be under >a different legal authority), the control operator is the required ID, not the >originator of the packet. It is not only about regulatory ID requirements but also about identifying who is behind some traffic. Many places have "relaxed firewall rules" for traffic originating from within AMPRnet. This already requires revision due to the sale of the upper block (I think that lots of firewall rules still mention 44.0.0.0/8) but also with more and more blocks being routed directly and having no transparency about the actual use of that space, I would like to know if some address is really an amateur or if someone has lend it out to shodan.io or stretchoid.com. And if so, at least know who is responsible for that. When that is not feasible, we will have to become more and more closed and more like the general internet (default drop everything). Rob

2 1

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>I am not sure what you mean by feared, but no, my allocations are not supporting the AMPRnet per se. If by AMPRnet you mean the legacy BBS style network of gateways and tunnels. I don't. With AMPRnet I mean what is described on the ARDC pages, not a set of applications and an old way to implement tunnels. So, the net44 address space and its use for amateur radio communications. Use for IRLP would be part of that. But in that case it should be possible to have reverse entries pointing to the callsigns involved. Rob

1 0

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>The reason I did this was because I needed PTR records in something other than ampr.org. I already feared that it was to conceal non-AMPRnet usage... This makes it all the more important to have zone transfer capability so the data can be used to validate against local policies. Rob

3 2

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 16 Jun '20

16 Jun '20

>I manage my systems, and all the HamBSD systems, with Ansible. Some API >would need to be provided to allow me to check the current reverse DNS >record (in the database explicitly, not just by performing a DNS lookup >that may be influenced by caching etc.) and to update the record. I have that fully working using a collection of scripts, but indeed it would be convenient when there was an easier and more modern API for it. As it is now, you can download the zonefiles from an FTP server (or of course you can do lookups at the master server ampr.org at 44.0.0.1) and compile a list of updates (using diff between the downloaded- and the desired info) and then you can create an e-mail message to the ampraddr robot that will do the updates. For this to work you have to have your mail sender address whitelisted. (it used to be an open service until it was abused) Rob

1 0

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 16 Jun '20

16 Jun '20

>On 16/06/2020 18:23, Rob Janssen via 44Net wrote: >>/Furthermore, I see that more and more subnets have arranged to delegate />>/DNS to their own servers. / >I had no idea this was an option. Who do I speak to to do this? It'd be >great to have actually up-to-date reverse DNS for my subnet. Why can't you submit updates to the main DNS server? What would be required for you to do so? Rob

4 3

VK AMPR Co-ordinator
by Gary B 14 Jun '20

14 Jun '20

Hi All, For info for those who knew Sam Scafe, VK4AA, who was the Australian AMPRnet Co-ordinator. SILENT KEY: - Samantha Scafe VK4AA Samantha went Silent Key on Saturday March 22nd at home in Cairns following complications from cellulitis interacting with a compromised respiratory system. Samantha had recently been in hospital a number of times but appeared to be improving before her health took a final dive. Samantha was one of the pioneers of Packet Radio networking in Queensland being one of the first to introduce the concept of data wormholes with the Aussie Wide Packet Radio Network. A move from the Gold Coast to Cairns found Samantha’s business become a ISP and Web Host/Design concern, including providing the backup site for the WIA News and QNEWS data files. Samantha and partner Colleen were also well known in autosports circles as CAMS Stewards, with many RadioAmateurs interacting with them at rallies and hillclimbs. Samantha also ran the Cairns APRS gateway for years and provided technical support for repeater builders around the country. The Australian Amateur Radio Service has suffered a great loss with Samantha’s passing and we pass on heartfelt condolences to partner Colleen and family. Vale Samantha Scafe VK4AA, Silent Key. >From Backscatter (Newsletter of the Townsville Amateur Radio Club) As a result, VK needs someone with AMPRnet and TCP/IP kwowledge and experience to volunteer to take on this role. If you think you are able to do this, or know someone who possibly could, please contact Chris, G1FEF asap. Currently VK does not have anyone to do the day to day co-ordination or issuance of 44. addresses. Regards, Gary VK4ZGB

7 6

ampr.org tls cert expired
by Scott Nicholas 13 Jun '20

13 Jun '20

Look's like the Let's Encrypt cert on ampr.org isn't running on a crontab :) -Scott

3 2

Re: [44net] NSP bugging me to use RPKI for my /24 grant
by Erik Seidel 12 Jun '20

12 Jun '20

Tom, It sounds like you're referring to delegated RPKI: https://www.arin.net/resources/manage/rpki/delegated/ I assume this could be done, but it would still have to be set up through ARIN first - just as in the case of hosted RPKI. Regards, Erik KE5SAI On Wed, Jun 10, 2020 at 11:26 AM Erik Seidel <erik(a)znsl.us> wrote: > > Tom, > > It sounds like you're referring to delegated RPKI: > > https://www.arin.net/resources/manage/rpki/delegated/ > > I assume this could be done, but it would still have to be set up > through ARIN first - just as in the case of hosted RPKI. > > Regards, > > Erik > KE5SAI > > On Wed, Jun 10, 2020 at 11:21 AM Tom Cardinal via 44Net > <44net(a)mailman.ampr.org> wrote: > > > > Cynthia, > > > > I only listed them as an example, my point was a having our own CA > > signed by a signing org that is trusted by RIRs. If that be ARIN then > > so be it. More importantly though, as you know, we have a legacy > > allocation. In my opinion we are equal to an RIR but with the ability > > to make global allocations from the 44.0/9 and 44.128/10 space. > > > > --ton/n2xu 44.98.63.0/29. > > > > > > On 6/10/20 7:38 AM, Cynthia Revström via 44Net wrote: > > > Tom, > > > > > > As Q already mentioned, Thawte or Comodo (now called Sectigo) are for Web > > > PKI, not RPKI, they have nothing to do with this. > > > And not to mention the huge requirements something like that would have, > > > and enormous fees. > > > > > > Not entirely sure what you mean by "act as an IR"? > > > > > >> They would have to accept it much like ARIN and RIPE trust each other > > > In the context of RPKI, ARIN and RIPE NCC do not trust each other, they > > > have their own Root CAs (TALs), which are independent of each other. > > > An RPKI validator has to use both of them. > > > > > > - Cynthia > > > > > > > > > On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net <44net(a)mailman.ampr.org> > > > wrote: > > > > > >> CA's like Thawte or Comodo won't work for this, they're for web PKI not > > >> resource PKI. > > >> The 44.0.0.0/9 cert would have to be signed by one of the RIR's trust > > >> anchors (probably ARIN since they have 44.0.0.0/8 assigned to them) > > >> > > >> Thanks, > > >> Q > > >> > > >> > > >> On Wed, 10 Jun 2020 at 13:28, Tom Cardinal via 44Net < > > >> 44net(a)mailman.ampr.org> > > >> wrote: > > >> > > >>> I've been monitoring this discussion. Since our space was allocated by > > >>> Jon Postel, initially around 1981 (ish), why can't we create our own > > >>> trust model (CA signed by a CA signing agency like Thawte or Comodo as > > >>> examples) and act as an IR for the 44.0/9 and 22.128/10 space ourselves > > >>> and publish that trust model to the RIRs? They would have to accept it > > >>> much like ARIN and RIPE trust each other. Then RPKI would work for > > >>> AMPRNet and AMPRNet would control it's own destiny. > > >>> > > >>> --tom/n2xu 44.98.62.0/29 > > >>> > > >>> > > >>> On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote: > > >>>> I can sympathize with the sentiment that RPKI and widespread RPKI > > >>>> adoption in its current form will really lock out and disenfranchise > > >>>> smaller network operators. > > >>>> > > >>>> Now, *more than ever*, we need to enable an Internet that any > > >>>> organization (a natural person, a registered entity, a hackerspace, > > >>>> etc.) can connect to, uniquely address itself, and begin exchanging > > >>>> traffic. > > >>>> > > >>>> In order to enable such an open system to function, we also need ways > > >>>> of ensuring that unicast addresses are unique and that there is some > > >>>> public, verifiable way of claiming ownership of IP space. Without > > >>>> this, the entire network is open to disruption and abuse by almost any > > >>>> operator. It's amazing we have gotten so far on the good will of most > > >>>> operators. > > >>>> > > >>>> The RIR model of lawyers, paperwork, and public databases works for a > > >>>> lot of people and organizations. IRR was the first step, but it was > > >>>> complex and a bit clunky to use. I see RPKI for Origin Validation as > > >>>> just the first/next step of extending this model of trust and > > >>>> numbering resource ownership into the routing protocol space more > > >>>> directly. > > >>>> From a technical standpoint, this logical extension of systems makes a > > >>>> lot of sense and I don't have a problem with it. > > >>>> > > >>>> For commercial network operators, a RIR registration is just the cost > > >>>> of doing business. > > >>>> But for many small nonprofits, regional amataur radio/network > > >>>> operators, or individuals, a few thousand dollars/euros a year is a > > >>>> lot of money that makes Internet independence out of reach. > > >>>> They end up having to resort to the hegemony of their local incumbent > > >>>> monopoly and chain themselves to the whims of their upstreams and > > >>>> regulators. > > >>>> > > >>>> I suspect many legacy resource holders find themselves in a similar > > >>>> limbo-state of not wanting to participate in the RIR model and pay > > >>>> money for essentially nothing. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Echoing some similar earlier sentiments to want to create a CA for > > >>>> legacy address holders: How feasible would it be to create something > > >>>> RIR-like, but noncommercial? > > >>>> A place for legacy address holders to coordinate and register > > >>>> resources seems like a natural fit. If we're going to operate a > > >>>> database of ROAs, we're going to need some database of address space > > >>>> ownership. > > >>>> For 44net use cases, this seems really straightforward, since we have > > >>>> the Portal to draw from. But for other organizations, it gets a bit > > >>>> more complicated to do properly. Given some random email > > >>>> address/account in some hypothetical legacy RIR, how can we really > > >>>> validate that they're authorized to take actions on behalf of some > > >>>> organization? > > >>>> To take some random examples from the IANA IPv4 list: DISA, USPS, > > >>>> AT&T, Apple, etc. Doing this right is going to take some process, > > >>>> record keeping, and well.... work. > > >>>> With this context, I can see how a lot of RIRs go commercial. However, > > >>>> with a bit of automation, good documentation and records, and some > > >>>> dedicated volunteers, this seems like a really doable/achievable thing > > >>>> in the netops community. > > >>>> > > >>>> I would be curious to know if anyone else shares these views/dreams > > >>>> and would like to chat about it. > > >>>> > > >>>> Stay safe and sane out there. > > >>>> > > >>>> Cheers, > > >>>> jof > > >>>> > > >>>> On Tue, 2 Jun 2020 at 08:18, Job Snijders via 44Net > > >>>> <44net(a)mailman.ampr.org> wrote: > > >>>>> Thomas, > > >>>>> > > >>>>> You say > > >>>>> > > >>>>> On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net > > >> wrote: > > >>>>>> DO NOT participate in RPKI! > > >>>>> And ... > > >>>>> > > >>>>>> We should be protecting our Internet!! Just saying... > > >>>>> What are you really saying? These statements seem at odds with each > > >>> other. > > >>>>> How do you protect your internet? Maybe I can learn some tricks from > > >>> you? > > >>>>> Kind regards, > > >>>>> > > >>>>> Job > > >>>>> _________________________________________ > > >>>>> 44Net mailing list > > >>>>> 44Net(a)mailman.ampr.org > > >>>>> https://mailman.ampr.org/mailman/listinfo/44net > > >>>> _________________________________________ > > >>>> 44Net mailing list > > >>>> 44Net(a)mailman.ampr.org > > >>>> https://mailman.ampr.org/mailman/listinfo/44net > > >>> > > >>> _________________________________________ > > >>> 44Net mailing list > > >>> 44Net(a)mailman.ampr.org > > >>> https://mailman.ampr.org/mailman/listinfo/44net > > >>> > > >> _________________________________________ > > >> 44Net mailing list > > >> 44Net(a)mailman.ampr.org > > >> https://mailman.ampr.org/mailman/listinfo/44net > > >> > > > _________________________________________ > > > 44Net mailing list > > > 44Net(a)mailman.ampr.org > > > https://mailman.ampr.org/mailman/listinfo/44net > > > > > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net

7 8

Modem
by Ken Adams 12 Jun '20

12 Jun '20

Hi Guys Looking for a UK compatible modem/router/DSL to use with TalkTalk. I can then switch off ALL firewall nat and filtering and pass ALL traffic through to my pfSense router/firewall and allow the usual 4 and 93 and ICMP. Waiting with hope in the heart 73 de Ken (G7OAH)

4 4

NSP bugging me to use RPKI for my /24 grant
by Jeremy Cooper 10 Jun '20

10 Jun '20

Hello all, In 2018 I requested and received a /24 allocation and permission to announce it via BGP. My ISP/NSP, MonkeyBrains.net, very graciously agreed to route it to my house as part of my normal residential service. (Quite amazing!) Now, however, they’ve sent me an unusual request (but they are excited about it): can I please setup RPKI for my IP allocation, authorizing them (MonkeyBrains) permission to advertise the block? Full quote below: > Hi Jermy, > > We advertise a /24 for AMPRNET. Please setup a ROA record on ARIN authorizing us to advertise that block. (We just learned how to do this for our IPs yesterday and are exctied about RPKI. > > > > If you haven't set up RPKI for your IP allocations, here are the steps in a nutshell: > > create SSL key > upload to ARIN > Create ROA (image below) > Thanks, > > Rudy > > HOW-TO on ARIN: > https://www.arin.net/resources/manage/rpki/hosted/#roarequestkeypair <https://slack-redir.net/link?url=https%3A%2F%2Fwww.arin.net%2Fresources%2Fm…> > I don’t think this is going to work as I don’t _OWN_ my block. It is licensed to me for a 5 year period. As such, there’s no record of my allocation with ARIN, and hence, nothing that I can assign. Do any of you network gurus have a sufficiently technically advanced response I can give the ISP for their request? 73, -Jeremy Cooper

19 34

pfSense
by Ken Adams 10 Jun '20

10 Jun '20

Has anyone got ampr 44net ipencap working.? I have a node running Linux/uronode/ax25/netrom/fbb and ampr-ripd. This then feeds into the pfsense box. AX25/Netrom/fbb are all working fine. I think I have IPENCAP on the firewall directed to the Node 198Lan address. All help very happily received. Rgds Ken (G7OAH)

3 2

Re: [44net] 44Net Digest, Vol 9, Issue 54
by Rob Janssen 04 Jun '20

04 Jun '20

> That vulnerability sounds quite like what alot of us have been saying for years....hummm...73,- Lynwood KB3VWG True! I have mentioned many times that it is best to filter incoming protocol-4 based on a list of valid gateway addresses, and also to filter traffic from those tunnels with filters allowing only AMPRnet addresses (except from amprgw when you use that to receive traffic from internet). We can only hope that this "discovery" and CERT registration will not lead to broad "protocol 4 blocks" by ISPs and transit providers, as has happened with NTP traffic when that was the topic. Maybe another motivation to move from the IPIP mesh to something more modern? Rob

1 0

Internet access
by Edward Young 02 Jun '20

02 Jun '20

Charles, thank you for confirming muy membership in the group. I am very interested in using a ham radio to connect to the internet. What equipment do I need and what do I need to do?

3 3

Mailing list
by Edward Young 02 Jun '20

02 Jun '20

I seem to be on the mailing list but I cannot post anything. Can you send me a link to confirm my membership? Edward Young

2 2

Re: [44net] 44Net Digest, Vol 9, Issue 54
by lleachii 02 Jun '20

02 Jun '20

That vulnerability sounds quite like what alot of us have been saying for years....hummm...73,- Lynwood KB3VWG null

2 1

CERT Vulnerability Note VU#636397: IP-in-IP protocol routes arbitrary traffic by default
by Chris KE2A 02 Jun '20

02 Jun '20

Reference: https://kb.cert.org/vuls/id/636397 OVERVIEW IP Encapsulation within IP (RFC2003 IP-in-IP) can be abused by an unauthenticated attacker to unexpectedly route arbitrary network traffic through a vulnerable device. Description IP-in-IP encapsulation is a tunneling protocol specified in RFC 2003 that allows for IP packets to be encapsulated inside another IP packets. This is very similar to IP GRE VPNs and IPSEC VPNs in tunnel mode, except in the case of IP-in-IP, the traffic is unencrypted at all times. As specified, the protocol unwraps the inner IP packet and forwards this packet through IP routing tables, potentially providing unexpected access to network paths available to the vulnerable device. An IP-in-IP device is considered to be vulnerable if it accepts IP-in-IP packets from any source to any destination without explicit configuration between the specified source and destination IP addresses. This unexpected Data Processing Error (CWE-19) by a vulnerable device can be abused to perform reflective DDoS and in certain scenarios used to bypass network access control lists. Because the forwarded network packet may not be inspected or verified by vulnerable devices, there are possibly other unexpected behaviors that can be abused by an attacker on the target device or the target device's network environment. IMPACT An unauthenticated attacker can route network traffic through a vulnerable device, which may lead to reflective DDoS, information leak and bypass of network access controls. -- 73, Chris KE2A

1 0

National AMPR Coordinator - info
by Marco Di Martino (IW2OHX) 30 May '20

30 May '20

Hi all, I have to do a formal communication to ARDC regarding the AMPR organization here in my Country. To whom should I address this ? Thanks Regards, Marco iw2ohx

1 0

Mikrotik help needed
by Ian Redden 29 May '20

29 May '20

Hi All; When trying to connect, the IPIP tunnel on my Mikrotik box is flapping. I am using Mikrotik OS 6.46.6. It connects, shows as registered/running, but after a random period of time, the link goes down. Eventually it reconnects and the entire process starts over again. While connected however, I am able to see the RIP routes. Configuration: /interface ipip add allow-fast-path=no local-address=24.xx1.xx4.44 name=ucsd-gw remote-address=169.228.34.84 Any ideas? Speed Test: https://cogeco-on.speedtestcustom.com/result/baacd8c0-a027-11ea-8085-870a92… Ian / VA3IAN

3 4

Portal is down
by G1FEF 29 May '20

29 May '20

Heads up, the portal appears to have crashed. Looking into it now… Regards Chris - G1FEF — AMPRNet Administrator

2 1

WWconvers Hub_NA
by Charles J. Hargrove 21 May '20

21 May '20

Looking to add another dimension to your BBS? Consider offering a chatroom to your users. There are several groups that meet worldwide on various channels, some channels are used locally for events/nets/emcomm and there are some that act as tech support for ham radio software programs. Here in NYC we use 14736 every Monday night as an alternate way to check-in to our weekly emcomm net (especially when encountering jammers). There is even a growing movement to use state or country-based channel numbers that reflect their 44net assignments like 4468 in NY, 4440 in UT, etc. Various packet bbs packages have chat capability built-in. I know of at least one station looking to incorporate it into FBB, but I have no information on that system. Connection to Hub_NA is easy. Use 44.68.41.2 (gw.n2nov.ampr.org). We currently have stations across the USA and Canada connected to Hub_NA. Come join us, ask questions and share your tips/tricks/ideas! -- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Nets 441.100/136.5 PL ARnewsline Broadcast Mon. @ 8:00PM NYC-ARECS Weekly Net Mon. @ 8:30PM http://www.nyc-arecs.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32 "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

1 1

Some config error in ampraddr
by Rob Janssen 20 May '20

20 May '20

Since today I get error reply mails from amprgw-adm-owner(a)caida.org on the mail I send to ampraddr(a)gw.ampr.org for DNS updates, which indicate that my mail is somehow forwarded to a mailing list at caida where I am not a member, and thus not allowed to mail: You have tried to post to a list you are not subscribed to. Only members are allowed to post to this list. It appears that the update itself is correctly processed, I get the confirmation mail, but also an error message. Anyone knows what is going on there? Rob

2 1

Routing from and to the internet
by Elias Basse 10 May '20

10 May '20

I have just completed setup on a ubiquiti router and am wanting to configure a host for some digital radio services behind the router but wish to use the 44 addresses out to the public internet to allow hotspots and repeaters to connect. Is anyone familiar with setting this up? From the server I am able to reach the internet but it is going out through an address from the isp rather than the 44 address. I used the ampr-ripd script from the wiki and can ping other 44 addresses. Hopefully this is possible, I have had my office allow use of some server and network hardware for ham radio. Best Regards Elias Kd5jfe Sent from my iPhone

3 4

Re: [44net] www.ampr.org
by Rob Janssen 20 Apr '20

20 Apr '20

>This may cause address conflicts once the addresses are used by the >purchasing entity. >It is probably best to implement a plan to move the addresses to a new >block. There is no need to move those addresses, they are not in the block that has been sold. Since a month or two we are routing 44.192.0.0/10 to internet (amazon) but this still causes issues as over 4000 systems in the 44.224.0.0/15 block have not yet been renumbered. (I get occasional complaints about systems no longer being reachable) Rob

1 0

Re: [44net] www.ampr.org
by Rob Janssen 20 Apr '20

20 Apr '20

> To make it work you need to route it via your public GW and NAT, so it > does not leave the router with your 44.x.x.x IP. > I think this is a little bit wrong, not to be able to access the portal > from a random HamNET IP. Well, it *does* work from a net-44 IP but it requires sufficiently well setup of the routing... When you have routing setup from the old days (like "route all 44.0.0.0/8 to the radio network") it will not work. It works OK here from my net-44 IP but still I could envision this would cause problems. E.g. just at the day the portal was down for the move, one amateur here wanted to move his system from the IPIP net to our local BGP routed network and he was unable to delete his gw. So he first setup the GRE tunnel and BGP routing but it did not work due to restrictions at our GW (having both IPIP and BGP does not work) and of course then he could still not reach the portal after it was back up. But he managed to do that from an external IP. Maybe the portal should not be in one of those 44.190 networks that are not supposed to be on IPIP, but it should be in another net-44 subnet that is both BGP routed on internet and IPIP routed on the mesh. Then it would work OK. Rob

5 4

Re: [44net] www.ampr.org
by Rob Janssen 19 Apr '20

19 Apr '20

> I could move it to a different block (not within 44.190/16) and set it up so that it’s part of the tunnel/mesh as well if folks think that will be better? That should solve the problem for Greg and Brian. For me it does not matter. When you do have an external address (which you should have for IPIP, please don't put a tunnel endpoint on a net-44 address!) you could also consider to put the external address in the DNS entry as well. Or maybe an IPv6 address for each of the systems. Rob

1 0

Re: [44net] www.ampr.org
by Rob Janssen 19 Apr '20

19 Apr '20

> Hi Rob, > Your browser is caching, clear your browser’s cache and try again. if you go to http it should redirect you to https > Regards, > Chris Now it does. This morning it did not redirect... Thanks! Rob

1 0

www.ampr.org
by Rob Janssen 19 Apr '20

19 Apr '20

When I visit http://www.ampr.org/ I get a page with only the text "www http" on it. When I visit the https site I get the usual site. Rob

8 8

portal down
by Ruben ON3RVH 16 Apr '20

16 Apr '20

Hi all, Anyone reported the portal down yet? Can't even read the server hosting it (81.174.235.134) 73 Ruben ON3RVH

8 10

Configuring a gateway with Ubiquiti Edgerouter 10x
by Keith Kasin 06 Apr '20

06 Apr '20

Greetings, I am trying to set up my Edgerouter 10x as a gateway. When I get to the step ubnt@ubnt:~$ set interfaces ethernet eth0 address <put your AMPRNet network assignment> I enter my allocation 44.18.50.0/28 and get an error. I can set 44.18.50.1/28 or just 44.18.50.1 however this does not yield a route when I enter the “show ip route” command. Should I be using my broadcast address, 44.18.50.15 in this position? I am sorry if I sound dense here so any guidance is appreciated as I work my way through this set up. Thank you, Keith AI6BX

2 1

Returning YV.
by Gabriel Medinas 01 Apr '20

01 Apr '20

Greetings to all, just to inform you that returning to teamwork at AmprNet, Venezuela is connected again, renewing some things in my local structure with the JNOS Linux program through yv5kxe.ampr.org (44.152.0.60). We are especially grateful to Chris - G1FEF who personally granted the possibility of this YV return on this network after 20 years. We are in settings, I am mainly working to adjust my old JNOS to the new dynamic of AmprNet especially to the RIP44d update that does not work in JNOS doing it manually, I am working on a project to use other compatible hardware to achieve other gateways for use APRS and the DXCluster yv5kxe. 73 de Gabriel YV5KXE yv5kxe.ampr.org

4 3

Ubiquiti AMPR-ripd
by Elias Basse 31 Mar '20

31 Mar '20

Is anyone familiar with ripd on the ubiquiti series of routers? I have a test device edgerouter pro that I am attempting to get working however I am unable to route through the ipip tunnel that has been built per both wiki articles. Any pointers would be appreciated. Many thanks, Elias Sent from my iPhone

1 0

BGP annuncement of same address Block from 2 sites ?
by R P 31 Mar '20

31 Mar '20

Hi there Is it possible to announce same Address Block from two different sites ? with preferred way for one site ? The idea is to have redundancy in case that one site connectivity fail the traffic will pass to the other site automatically Both site will be connected by radio as well so Network connectivity will not stop I know that BGP support it is it also the way in the AMPRNET BGP announcement ? Has anyone done it ? or doing it in the AMPRNET community ? Thanks Forward Ronen - 4Z4ZQ

3 2

BGP Announcment Procedure
by R P 31 Mar '20

31 Mar '20

Hi there Who deal today with BGP announcement procedure ? We want to start announce part of our 44 net BGP i started the procedure with Brian who take care of it now ? Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org

2 1

Re: [44net] Large increase in inbound suspicious traffic from public internet to systems on 44 net?
by Rob Janssen 31 Mar '20

31 Mar '20

> On Thu, 2020-03-12 at 11:30 -0500, Shawn M Garringer via 44Net wrote: > > I am wondering if anyone else is seeing the following: starting on 5 > > March 2020 and continuing through the present I have detected a large > > spike in inbound traffic to several of my AMPR 44 IP addresses (on > > 44.50.1.0/24). The spike has been large enough that my logging ELK > > stack is struggling to keep up. > A good number of folks have seen a spike in scans by botnets spoofing > IPs but not just on 44-net. Commercial ISPs have seen similar spikes of > traffic and have taken proactive measures to try and halt these brute > force attacks. I see no visible increase in the traffic graphs for our internet gateway, but of course I do confirm that there is a continuous stream of port scanning going on, partly from individuals and partly from jerks like censys.io, shodan.io, stretchoid.com, binaryedge.ninja etc etc who are continuously scanning the internet for vulnerabilities and keep searchable databases where their users can instantly locate who is running e.g. a MikroTik router when there is a new known vulnerability (of course only when it its firewall is not properly configured). All this together is responsible for 1-2 Mbit/s of traffic on our /16. So yet, it is quite noticable. Of course we do not log all that, but we do have some auto-block features that trigger when people scan for wellknown ports (like mentioned above) within unassigned address space. Rob

2 1

Large increase in inbound suspicious traffic from public internet to systems on 44 net?
by ampr＠shawngarringer.org 30 Mar '20

30 Mar '20

Hello group, I am wondering if anyone else is seeing the following: starting on 5 March 2020 and continuing through the present I have detected a large spike in inbound traffic to several of my AMPR 44 IP addresses (on 44.50.1.0/24). The spike has been large enough that my logging ELK stack is struggling to keep up. This traffic is coming from the public internet. Most of these are looking at standard ports 443, 80, 25, and 22. These are being directed to IP addresses in my subnet that are not in use, and therefore are being dropped (but logged) at the firewall. Nothing is running on these IPs so there is no way the traffic is in response to anything I can find coming from my network. I realize devices periodically scan the "entire internet" but this is more than that... in one day I saw 100,000 TCP SYN from a single public IP address. That is a significant spike and I am not certain why they sent so much traffic from a single IP to a single IP. Wondering if anyone else is seeing the same? 73 DE KC0AKY

7 9

Re: [44net] Security - Nested IPIP
by Rob Janssen 27 Mar '20

27 Mar '20

> So all traffic received on IPIP tunnels should be from net44 only in our case. Unfortunately not all of it is. > Can you elaborate on the traffic that isn't, please? > Is this traffic from another operator...or a non-operator? > Can you also elaborate if this traffic forwards in any cases? As I explained before, what I sometimes DO see is IPIP traffic from gateway A.B.C.D with an internal packet with source A.B.C.D and destination 44.137.X.Y (inside our network). That traffic should have been sent with source address 44.P.Q.R in the internal packet, where 44.P.Q.R is the net44 address of that specific gateway at A.B.C.D. As I got repeated logs in the firewall of these occurrences (one was from a Polish gateway, I remember) I added a firewall rule to allow such traffic. The reply will of course be routed directly over internet, not via the tunnel, so it is questionable if the connection would get established. Probably not, when the user has the typical stateful firewall on his internet connection. Yesterday I have removed the extra rule and I am watching the firewall log, but I have not yet observed another instance of this error after about 12 hours. So maybe some people have woken up and fixed their config already. Rob

1 0

Re: [44net] Security - Nested IPIP
by lleachii＠aol.com 26 Mar '20

26 Mar '20

Rob, You stated: So all traffic received on IPIP tunnels should be from net44 only in our case. Unfortunately not all of it is. Can you elaborate on the traffic that isn't, please? Is this traffic from another operator...or a non-operator? Can you also elaborate if this traffic forwards in any cases? That's what we're tying to stop. Please note, I haven't identified this is related to any IPENCAP issue specifically (except that it appears we may have some operators that forward traffic not destined for them). While I understand your concern, I'm not sure it's related to IPENCAP 100%. 73, - Lynwood KB3VWG

2 3

Re: [44net] Security - Nested IPIP
by Rob Janssen 26 Mar '20

26 Mar '20

> I'm now wondering how such a config is [incorrectly] made (i.e. the inside Header has the incorrect SRC)....likely because of no route policy...another discussion... Easy: when you take a default Linux system and add something like IPIP mesh with routes in the same table, and then you run services on the same system, an outgoing connect to a system within net44 will just consult the routing table, find an outgoing route and make a connection. You then have to rely on the "source address selection" done by the system, which may select your public IP as the source address. This may also be configured in the service itself (when the socket is not bound to 0.0.0.0 but to some specified address). The outgoing connect will now be routed through the IPIP tunnel, but it will have the public address as the source. To prevent this, the service would have to be bound to the net44 address, or it would have to be set as a default source address in the tunnel routes in the table. When you run a separate system as the IPIP router and an AMPRnet services host, you do not run into this problem because the services host has the proper external address within net44 and the router will not change it. But with both combined in a single host, you can still get it working correctly when you pay some attention. Which of course has to be done when you want a single system that can both be a general-purpose internet browsing system (directly via your ISP connection) and can be an AMPRnet services host at the same time (also for services available from public internet addresses). The routing has to be carefully set up when doing this, and setting a preferred source address is only part of that. In our network the problem you mention w.r.t. AMPRGW does not occur because internet traffic is routed directly to our gateway, not via an IPIP tunnel. The IPIP tunnel via AMPRGW only gets public internet traffic when our BGP announcement is down for some reason, that is why I kept it operational but it normally has zero traffic. So all traffic received on IPIP tunnels should be from net44 only in our case. Unfortunately not all of it is. When I "just drop" the bad traffic it appears in a log and it appears the originators of the traffic do not notice it, so it goes on and on. As I mentioned, I sent mail to gateway owners about it, but it rarely fixes the situation. Rob

1 0

Re: [44net] Portal/Wiki text
by Rob Janssen 26 Mar '20

26 Mar '20

> One minor thing to bring up though, since I went and re-read the text. It says > "ISPs don't configure their routers with publicly routable IP space for end users, why would you?" > This is by and large false. Some do indeed use 1918 space for customer facing interfaces, but most do not, as this practice this can break PMTUD due to dropping PTB messages sent by 1918 numbered interfaces and is not generally not recommended. It looks like this came from the HamWan people who apparently use a lot of RFC1918 addressing, I think at first even their whole network was on RFC1918 space and they introduced net44 capability only later. However, in our network here we exclusively use net44 addresses, also for links and routers. Of course we do have appropriate firewalls in place. The first line of defense is that at the internet router, all incoming traffic is blocked by default unless the destination is from an address list of only systems that provide services that are to be visible from internet. And in the last router before the actual system there is an additional firewall that opens only certain ports for everyone, and restricts management ports to another address list that has only addresses of known operators, or at most the country subnet. This makes the result similar to using RFC1918 addressing (which provides protection because it can only be routed locally), but without the disadvantages that you mention. Anyway, I am not that much concerned about that part of the text, it will depend on local policies and we do not use that method of subnet allocation anyway. My main concern at this time is that "outsiders" (not licensed radio amateurs) apparently find our network in their search for IPv4 address space, and make requests that we have to reject. This rejection often leads to discussion (partly because there is no terminate-this-request option in the portal, a coordinator can only accept it or send it back to the requester for more detail). Therefore I think it would be best when those outsiders immediately see that this system is not for them. Rob

2 1

Re: [44net] Security - Nested IPIP
by lleachii＠aol.com 26 Mar '20

26 Mar '20

Rob, I now understand what you meant by this. I'm not seeing [lots of] improper Header 1 traffic with a known gateway IP as a SRC IP (and if I do, I want to block as it's asymmetric, as I tax AMPRGW on the reply trip). I receive the packet from AMPRGW (i.e. they're using the Public Internet instead of AMPRNet to reach the NTP server). * AMPR <> AMPR (OK, This allowed - as I list this service to my subnet in the Wiki) * Registered_Public <> Registered_Public (OK; but closed for MOST services) * Registered_Public <> AMPR (OK, not announced, taxes AMPRGW - may close soon; closed for some services) * Tunnel (Header 0) <> Public IP (Header 1) (NO - I consider this a crafted packet or improperly configured gateway, creates asymmetry; and taxes AMPRGW on the reply) - but cannot be mitigate except by blocking registered gateways on the de-encapsulated side of tunl0 I would advise you block that traffic with an improper Header 1 from registered gateways of you flag it via Header 0. But this discussion now causes me to recall discussions we've had before on: 1.) the security of seeing the Registered Public IP on both sides of the tunnel 2.) policy-based routing and the need to separate routing tables comes to mind....this comes from operators' failure to set that up. I'm now wondering how such a config is [incorrectly] made (i.e. the inside Header has the incorrect SRC)....likely because of no route policy...another discussion... Just note that bad IPENCAP is not the majority of bad traffic we're seeing on some nodes...in fact, bad IPENCAP is the least of this traffic (at least now). - KB3VWG Unfortunately this breaks legitimate traffic because some gateways are incorrectly configured (as I mentioned before) and send tunneled traffic with their own external address as source address, instead of the AMPRnet address assigned to the gateway. So such traffic is accepted as well here (i.e. traffic with a source address of one of the gateways)

1 0

DNS procedures/process
by Elias Basse 26 Mar '20

26 Mar '20

Are there any updated dns procedures with regards to coordinators? I have a new coordination and haven’t done it in a while and can no longer find the email with the procedure for adding dns. At one point I thought this was in the portal. Best Regards Elias Kd5jfe Louisiana AMPR coordinator Sent from my iPhone

2 1

Re: [44net] Portal/Wiki text
by Rob Janssen 26 Mar '20

26 Mar '20

> The relevant page has been updated with your suggested dialogue Thanks! It is at least an attempt, let's hope it works. Other coordinators beware: there is a hosting company owner from the Netherlands that is apparently shopping for a subnet. After I rejected him, he tried in Germany. Rob

4 3

Re: [44net] Security - Nested IPIP
by Rob Janssen 25 Mar '20

25 Mar '20

> Please keep in mind though, the malicious traffic I observed did not originally come from AMPRGW. I originally observed the nested IPENCAP traffic from a Polish Public IP that's still currently registered as an AMPRNet gateway. As you know in later Linux kernels it became more difficult to see the outer header of the IPIP packet in a firewall rule handling the tunneled traffic. To circumvent that, a couple of years ago I added a rule to the firewall that sets a packet mark on traffic received from AMPRGW (matching the source IP in the outer header). This packet mark can then be checked in the firewall for the tunneled traffic. Source addresses outside AMPRnet are only accepted when the packet mark is set. Unfortunately this breaks legitimate traffic because some gateways are incorrectly configured (as I mentioned before) and send tunneled traffic with their own external address as source address, instead of the AMPRnet address assigned to the gateway. So such traffic is accepted as well here (i.e. traffic with a source address of one of the gateways) We really should abandon the IPIP tunnel mesh and move on to something a bit more secure (and easier to use on modern equipment)... Rob

1 0

Re: [44net] Portal/Wiki text
by lleachii＠aol.com 25 Mar '20

25 Mar '20

Rob, The relevant page has been updated with your suggested dialogue: http://wiki.ampr.org/wiki/Requesting_a_block 73, - Lynwood KB3VWG

1 0

Re: [44net] Security - Nested IPIP
by lleachii＠aol.com 25 Mar '20

25 Mar '20

David, 1. OpenWrt is Linux; and my previous gateway ran Ubuntu Linux (no *nos) - I cannot speak to other Routing Planes running IPENCAP tunnels. Also note machines running tnos have the machine's kernel and userland software to possibly interact with a packet. I only surmise without firewalls, some of the basic routing concepts apply to other Network Operating Systems too. 2. We're running AMPR gateways, so routing would be ON - I'm lost at the remark about IPv4 Forwarding = OFF. It seems as if you're suggesting to "disable routing on the router". I can only speak for Linux-based devices that are also performing functions as an actual router. Servers (i.e. with net.ipv4.ip_forward=0 and net.ipv6.ip_forward=0) merely receiving all of your IPENCAP packets should not apply here. Even when I originally ran a Linux server as my APMRNet device - downstream of my border router, I still had a /24 (253 other usable IPs) - so I've always had the need to route some IPs. You asked: Are these users trying to break into our AMPR hosts due to gaps in our firewalls or are they exploiting incomplete firewalls to use them as relay hosts to SOURCE attacks out on the Internet? Answer: Both are logically possible with an unfirewalled router or device and/or policy route isolation of the interfaces (in the case of a router). I described a scenario where a malicious actor can use the asymmetry of the routing to get a login screen (e.g. of your router or server) only accessible locally. It also seems as if DDoS is a consequence, or the modus operandi, of some traffic (e.g. TCP reflections cause 100% open connections at the router or a machine). 2b. These would be firewall rules to mitigate. 3. I have provided: tcpdump outputs and netflow records, the tcpdump command to observe the nested IPENCAP and a netflow log of a packet which (had it not been firewalled) could have double routed across my device - let me know what additional filters are needed. Also, the device running the dump must be your registered gateway (to which these actors are directing the traffic in this discussion), not a random device on the Internet. https://linux.die.net/man/8/tcpdump Nested IPENCAP: tcpdump -vvv -n -i tunl0 proto 4 I haven't thought of a tcpdump to observe all Header 1 routing - as the vice versa SRC/DST could be valid in some instances - this command only shows traffic entering or exiting tunl0 without your IP...it will also hit FALSELY on the RIP44 packets, hence the last part: tcpdump -vvv -n -i tunl0 src net not 44.60.44.0/24 and dst net not 44.60.44.0/24 and not host 224.0.0.9 4. I have posted the Second header scenario and it's remains available at the Wiki page. There should be no 3rd header scenario - that's the malicious activity the Second Header firewall rule blocks. http://wiki.ampr.org/wiki/Firewalls (and see previous emails on this topic) - FYI, there's nothing 44net-specific to the rules I suggested - # THIS PREVENTS NESTED IPENCAP (BCP 38) iptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP HTTP Rule (OpenWrt syntax - iptables-based): config rule option target 'ACCEPT' option proto 'tcp' option name 'AMPR_WWW' option family 'ipv4' option dest_ip '44.60.44.10' option dest_port '80' option src '*' option dest 'amprnet' option extra '-m limit --limit 25/minute --limit-burst 100 -j ACCEPT' Block first TCP packet not SYN (again, OpenWrt syntax - iptables-based): config rule option proto 'tcp' option name 'Block_In_Not_SYN' option src '*' option target 'DROP' option extra '! --syn -m conntrack --ctstate NEW' (Also the normal SYN Flood and INVALID rules). 5. Yes you can have DNS records and not receive traffic from AMPRGW - just block it and/or remove its route. Following the Wiki (for an Linux or OpenWrt setup), the only allowed traffic from anywhere by default are routes from AMPRGW, so long as the machine's default iptables rule is drop or reject. So it's alarming to hear inquiries like this. This will not stop the actual IPENCAPed packets from the Internet via AMPGW for the IPs in the DNS zone. Please keep in mind though, the malicious traffic I observed did not originally come from AMPRGW. I originally observed the nested IPENCAP traffic from a Polish Public IP that's still currently registered as an AMPRNet gateway. 73, - Lynwood KB3VWG

1 0

Re: [44net] Security - Nested IPIP
by lleachii＠aol.com 24 Mar '20

24 Mar '20

All, I wanted to make 2 notes regarding: dynamic IP addresses and AMPR TCP-based services. * An operator mentioned that it may perhaps be malicious dynamic IPs (no longer used by the operators in question) that are sending this traffic...I also think the [malicious] experience "via RIP[44]" had not occurred was noted... Since my gateway is in fact dynamic and still seeing issues...wouldn't it be prudent for those operators that are monitoring AND FIREWALLING their gateways to identify the rogue gateways for removal and dropping? Because, if they're rogue operators...**we now understand how our routes are being leaked**...as they are successfully relocating my new Public IPs (even though I'm dropping routing traffic and IPs out of tunl0 that != my allocation). * All operators running TCP services should ensure they are not reflecting SYN-ACK packets and/or experiencing half-open connections on the router and server as a result. Firewalling new TCP connections CONNECTION_STATE not SYN (unless you expect such traffic) and burst rules help. In OpenWrt, such activity can be easily seen on the Overview Page upon login at "Active Connections" graphic. ** I suggest as an extreme measure for those who have not blocked IPENCAP on tunl0 only to operators in the past - to do so; and/or renumber their router interface(s) possessing AMPR IPs (the IP does not need a DNS record if it doesn't need access from AMPRGW/Public Internet). This mitigates the malicious actors' ability to perform nested routing on your device. ** It is now apparent that 2nd and 3rd headers need to be properly firewalled on all gateways running IPENCAP. Be vigilant. ** Please make sure no internal LAN devices were compromised (thru asymmetric traffic that may have allowed a malicious person access to LAN machines). ** Nested IPIP can be firewalled (i.e. Header 2 - the third header); but there is no known solution to receiving a packet with a malicious Header 1 (i.e the second header - which could be expected to reach any device on Earth with a Public IP). Properly firewalling and monitoring traffic that you allow into your 44network (with 44net IPs) is important. ** If anyone running a Linux-based router can WireShark/tcpdump and observe MAC addresses directly on their tunl0, please let me know. This is believed a hash of the 4 SRC/DST IPs of Headers 0 and 1 - which could be used to authenticate traffic from gateways that != AMPRGW. 19:39 UTC 23MAR2020: 269 11.96 KB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop 844 76.12 KB zone_amprwan_dest_DROP all * * !44.60.44.0/24 0.0.0.0/0 - Drop-AMPR_OUT_InvalidSRC This is ~30 seconds of traffic of drops from my router to forwarding of invalid Header 1 receipts. The first rule is all traffic from you in which KB3VWG != DST IP; and hence you asked me to route it for you. (I only allow this by coordination). It should be 0. I should note the second rule includes drops from my AMPRLAN that != bogons - but should otherwise be 0 too (e.g. unfirewalled, the packets could forward to BGP 44 IPs that exist on an operator's routing table as "properly NATed traffic" from an allowed gateway). 73, - Lynwood KB3VWG

2 1

Portal/Wiki text
by Rob Janssen 21 Mar '20

21 Mar '20

Can someone please add some explanatory text to the relevant portal and wiki pages that inform the visitor that AMPRNet is a closed network that is only accessible to licensed radio amateurs. I got another of those requests that come from people that are just after some free IP space and submit an allocation request through the portal using some "handle" like used on whois as their "callsign". They probably find us using some search and then land on portal.ampr.org, make an account and file an allocation request. When walking that route, there is no information at all about the target audience, all information is just geared towards "how to request IP space", which they do. In the latest case, when I rejected the request saying it is only for licensed amateurs the request was re-submitted with a callsign which is not assigned to the person making the request. He probable searched again to find what licensed radio amateurs are and found some callsign that he then added to the request. (not knowing that we can do reverse lookups on those) They should at least at some point encounter some text that explains them that this network is not for their hosting purposes. Rob

1 0

Security - Nested IPIP
by lleachii＠aol.com 16 Mar '20

16 Mar '20

All, The following are RAW firewall hits indicating nested IPIP in IPIP packets. I run a firewall that only allows IPIP from all of you (and rules that only allows the AMPRGW routes and my destination IPs); but since this is a RAW rule - it implies nothing of any operator. I have not reviewed my Netflow records; but please be vigilant of this traffic. I warned of this issue in the "ancient" 44 mailing archives. Table: RawChain PREROUTING (Policy: ACCEPT, 94829408 Packets, 59.38 GB Traffic)Pkts. Traffic Target Prot. In Out Source Destination Options Comment32 2.37 KB DROP 4 tunl0 * 0.0.0.0/0 0.0.0.0/0 - - 73 ::and elbow bump::, - Lynwood KB3VWG

4 18

Re: [44net] Security - Nested IPIP
by Rob Janssen 16 Mar '20

16 Mar '20

> * Some of you query the NTP with your Public IP thru AMPRGW instead of directly to me thru the mesh (just a note to make your SRC IP an AMPR address, not your Public IP - I may disable your access thru AMPGW in the future, as it's announced as "AMPR-only") Unfortunately it is quite common for gateway stations to send tunneled traffic towards 44net addresses (via IPIP) with a public IP as the source. I normally block all such traffic, except when the public IP is the gateway public address (as I got tired of trying to reach sysops where this error was present). People *should really use* proper source address selection and policy routing and NOT send tunnel traffic with other than 44net traffic (both source and destination) inside it to any gateway station except by prior agreement. (e.g. AMPRGW can send traffic from a 44net address to public destination addresses, and so can some gateways) To make life easier, DO NOT TRY to setup a gateway on the same system where your applications are also running, unless you have good knowledge of networking configuration and know about such concepts as policy routing (ip route rule, multiple route tables) and setting a preferred source address in a route. When you use a separate router and application machine, such errors are much less likely to occur, and configuring the firewall is also much easier. Get a separate Pi or MikroTik or whatever to run your gateway, and then have a PC or another system to run your BBS or conference or whatever you want to run on AMPRnet! Rob

1 0

Re: [44net] Security - Nested IPIP
by Rob Janssen 14 Mar '20

14 Mar '20

> Those with a dynamic address CAN participate as their public gateway > can now be a FQDN for their dynamic service. I have some within the > New York State subnet (44.68/16). The issue is that IPIP tunnels have to be validate with their external address for at least SOME security, and this means that when the address changes there is nothing else we can do than drop their packets until the change comes through the portal and RIP system. With a system that has those dynamic addresses connect only to one or two VPN routers in a secure manner (e.g. L2TP/IPsec) we would not have that problem. Also, those address changes would not be important to other systems on the network. Out of the 561 registered gateways, we only ever receive traffic only from 73 of them. (the others could be either inactive or not be sending traffic to the Netherlands) Their address changes would not be important to us. Rob

1 0

Re: [44net] Security - Nested IPIP
by Rob Janssen 14 Mar '20

14 Mar '20

> The spoofing is happening on GRE too...GRE was first. But with the GRE/IPsec and L2TP/IPsec tunnels spoofing is impossible. Rob

1 0

Re: [44net] Security - Nested IPIP
by Rob Janssen 14 Mar '20

14 Mar '20

For a long time now, I have been allowing IPIP only from registered gateways and disallowed nested IPIP. Indeed I have seen in the past that IPIP packets were sent with the intention of being forwarded through "allow trusted subnets" rules and then maybe back out to internet hosts that were targeted for DDoS or similar. When looking in the logs of those rules, I usually see dropped packets from hosts that are apparently on dynamic addresses and have changed address, but this change has not yet reached me through the ampr-rip announcements. However, there are indeed also instances of apparently unrelated intrusion attempts. It remains my position that we should change from this IPIP mesh to a more modern VPN system where stations with dynamic addresses can participate through a local VPN server that participates in a network that uses standard protocols to form a dedicated AMPRnet tunnel network with automatic routing, that can be used by standard equipment and can be made more resilient against unwanted use (e.g. by using GRE/IPsec and L2TP/IPsec tunnels instead of the traditional IPIP). However, I no longer want to beat a dead horse. We had the discussion a while ago but unfortunately it was then redirected onto a separate mailing list. Rob

2 1

Venezuela AmprNet
by Gabriel Medinas 14 Mar '20

14 Mar '20

Greetings to all the other colleagues and friends, I am Gabriel Medinas YV5KXE from Caracas, Venezuela. For years (20 years) I have been coordinator of the AmprNet network for Venezuela with assignment 44.152.0.0 / 16 trying to assign and maintain the network of radio amateurs on network 44. For some unknown reason, I do not have access to this coordination and I use this route to try to communicate with people who can help me restart the Amprnet network through my gateway in Caracas yv5kxe.org. and with the knowledge of the pass way of Brian Kantor, the communication has been more complicated for me. I have register in AmprNet Portal and have register my Gateway yv5kxe.org Jnos linux 2.0j, telnet port 2332, Convers, DXcluster, Netrom link USA (laxnet), Caracas City. I appreciate any help in solving this problem in the sense of being able to restore the service over the local networks of Packet Radio, CONV, and NetRom. Thank you. Gabriel YV5KXE 4M5G gmedinas.com

1 0

Hub_NA Changes
by Charles J. Hargrove 08 Mar '20

08 Mar '20

With the shutdown of the WA7V system after a long and dedicated stretch, Hub_NA of the WWconvers needed a new home. With the help of WA7V and testing with KD6OAT, Hub_NA is still functioning but with a new IP address of 44.68.41.2 (gw.n2nov.ampr.org) on port 3600. The software also has the capability to make use of IRC clients that we might get included in a future version of JNOS. All bbs sysops in North America are welcome to connect their chat clients and servers to Hub_NA and join the rest of the WWconvers network. There is plenty of room for specialized convers channels. For the 44Net allocations in NY State (44.68/16) I suggest a common channel of #4468 to chat among ourselves. -- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Nets 441.100/136.5 PL ARnewsline Broadcast Mon. @ 8:00PM NYC-ARECS Weekly Net Mon. @ 8:30PM http://www.nyc-arecs.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32 "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

6 10

MTU standardization for tunnels?
by Rob Janssen 04 Mar '20

04 Mar '20

In our local network we have several different kinds of tunnels, with different header overhead. As the usual MTU on an internet connection is 1500 (the ethernet MTU), the typical MTU for an IPIP tunnel is 1480, for GRE it is 1476, for GRE6 it is 1454, etc. However, not everyone has a 1500 byte internet MTU. Some people have PPPoE connections to internet with MTU of typically 1492, sometimes 1480. So the effective MTU of the mentioned (and other) tunnel types becomes 8 or 20 bytes less. Some people get a fixed address subnet from their ISP and it is provided as some tunnel with an MTU of 1456 (quite common here). This results in a wide variety of MTU values in our network. Frequently issues arise for new connections where the chosen MTU for some tunnel turns out to be too large, and full-size packets are dropped. And in an environment where those tunneled packets encounter a point where the outer packet is too large for the interface MTU, the usual mechanism of returning "ICMP destination unreachable, fragmentation required" does not work very well, because the ICMP is returned to the router that encapsulated the packet, not the original source of the traffic. And I have never seen an encapsulating router that translated the ICMP to a new ICMP packet referring to the inner addresses and sent it back to the original source. Also, there are sometimes issues when routes are changed by BGP. Of course many routers have TCP MSS clamping configured where the TCP MSS is reduced whenever the TCP SYN passes through a place with lower MTU, but this happens only on the initial connection setup. When the MTU later reduces due to a route change, this still results in failure of the connection. I wonder if other gateway operators have done something to alleviate this problem. Solutions that can be considered: - ignore DF. much of the current TCP traffic has DF (don't fragment) set, but this often causes communications to unnecessarily break. Without DF, packets would be fragmented as originally designed in the IP protocol. sending everything with DF and interpreting the ICMP responses is the mechanism behind "Path MTU discovery", which was designed to avoid fragmentation and the overhead it causes in routers. however, in the AMPRnet we seldomly encounter so much traffic that CPU loading of the routers is an issue. - standardize on a "default MTU" whenever we cannot offer a 1500 byte MTU. this does not solve all problems, but at least it solves some of them. Note that most routers fragment packets in a particularly inefficient way. When a packet a few bytes too large for the next hop has to be forwarded (and DF is not set), they will not split the packet in two approximately equal halves, but rather they send a first fragment as large as the outgoing MTU can accept, then a small fragment with the remainder of the original packet. This can result in multiple fragmentations along the way: first it has to be fragmented to fit into a 1480 byte MTU of an IPIP tunnel, then further on it has to be fragmented again to fit a GRE or L2TP/IPsec tunnel with smaller MTU. Whereas no further fragmentation would be required when it had been split in equal halves the first time. So, I wonder what others do (if anything) to avoid the problems caused by oversized packets and maybe to avoid fragmentation. For some time, I have experimented with "ignore DF" and of course it keeps traffic flowing, but it is unclear if it causes problems for some users. Next I would consider to use a standard MTU value on all tunnels, so there are mostly two MTU values left in the network: 1500 and that smaller, to be determined, value. Of course the MTU should not be so low that it causes terrible overhead. In the past we had a 256 byte MTU on AX.25 packet radio (or even 216 when it was over NET/ROM), but that causes a 15% header overhead and made us very unpopular amongst plain AX.25 users. Fortunately the WiFi links we use today allow 1500 byte packets :-) The minimal required MTU for IPv6 is 1280. The maximal MTU we can accomodate with the worst case tunnel headers is about 1400. So the preferable default MTU would be somewhere between 1280 and 1400. Are people even using 256-byte MTU links today? Would it be worth it to select an MTU value that can be more efficiently fragmented into 256-byte packets? Or is there another small MTU size that would be a candidate for such considerations? So again, I wonder what others have done w.r.t. this matter. Are admins of gateways that offer many kinds of different tunnels using a standard MTU in their systems, or just the max MTU that each tunnel technology allows? Do you copy DF from the inner to the outer packet in a tunnel? Do you ignore DF? What would be your position on establishing a standard MTU for tunnels, and what size would you propose? Rob PE1CHL

2 1

Auto Reply
by William Bressette 01 Mar '20

01 Mar '20

Auto Reply to Test EMail Titled [44net] Consider some tests

1 0

Consider some tests
by lleachii＠aol.com 01 Mar '20

01 Mar '20

All, I have a question to ponder again. In preparation for emergencies, I wanted to consider some of the following. - Passing traffic thru another GW, we can use the test/example subnet - If AMPRGW at USCD is unreachable, could we have other capable devices that elect between themselves and announce the routes from Chris' server? - Can we test the redundancy of Chris' route server from whom they elect and receive - I'm not sure if anyone is doing AX.25 to IP or vice versa; but I would like to try - I'm curious if anyone has compiled kissattach and all utilities compiled; etc. in OpenWrt to connect a TNC and radio - I want to do an end-to-end test (I recall someone offered me a makefile for some libraries) - I want to migrate my base APRS radio to the router. I recall I have libax25 compiled... 73, - Lynwood KB3VWG

1 0

Re: [44net] Seeking BGP Guru
by lleachii＠aol.com 25 Feb '20

25 Feb '20

All, I think there's big confusion here between what's called in the industry "Settlement Free Peering" and "paid transit services." Comcast offers "Ethernet Dedicated Internet" service in my area (Washington, DC). They offer: Static IPs, DHCP and a BGP session. In this service, Comcast will not allow the user to BGP to a third party with the intention to use Comcast for carrying the 3rd party's traffic. This is simply called "paid transit service". When we refer to getting a BGP session with another AS for AMPRNet, look for "BGP transit service" plans. Peering would be considered traffic between Comcast and another large ISP (i.e. the peering agreement would be relevant if e.g. USCD - AS7377, wanted to peer with Comcast). That's called [settlement free] peering (in a Tier 1 ISP's terminiolgy). About the product: https://business.comcast.com/enterprise/products-services/data-networking/e… For a list of cities with the product: https://business.comcast.com/enterprise/products-services/data-networking/m… 73, - Lynwood KB3VWG

3 2

Re: [44net] Message for Chris, G1FEF about 44.135.92.8/29
by Bob Tenty 24 Feb '20

24 Feb '20

I replied to you from my gmail address Bob On 2020-02-24 17:27, G1FEF via 44Net wrote: Bob, nothing received from you. I have sent you an email, please reply to if or let me know here if you don't receive it. Regards, Chris

1 0

Re: [44net] Message for Chris, G1FEF about 44.135.92.8/29
by Bob Tenty 24 Feb '20

24 Feb '20

Chris, I wrote you an email from my address as listed in the portal. Hopefully you received it this time. Bob On 2020-02-24 07:24, G1FEF via 44Net wrote: Hi Bob, On 24 Feb 2020, at 12:14, Bob Tenty via 44Net <44net(a)mailman.ampr.org> wrote: Chris, Sorry to write you in this way but I tried to reach you since the end of October of last year with emails without any reply. Also an email from the portal itself received no reply Please email me here: chris(a)g1fef.co.uk that should reach me. Thanks, Chris

2 1

Message for Chris, G1FEF about 44.135.92.8/29
by Bob Tenty 24 Feb '20

24 Feb '20

Chris, Sorry to write you in this way but I tried to reach you since the end of October of last year with emails without any reply. Also an email from the portal itself received no reply I need the follow change. I route and have an entry for the subnet 44.135.92.0/24 Ron, VE3CGR wants to route the 44.135.92.8/29 part himself. He is registered in the portal. Can you add 44.135.92.8/29 to this entry? Please leave the rest of my 44.135.92.0/24 subnet intact. Many thanks, Bob (Boudewijn) VE3TOK -- There is nothing permanent except change Heraclitus

2 1

Seeking BGP Guru
by William Lewis 24 Feb '20

24 Feb '20

Good evening. I am looking for someone who would be an expert in BGP and using Comcast for the transport. Please contact me off list. I have some questions I'm looking to get answered. Thank you, William Lewis / KG6BAJ wlewis(a)myhostingsource.com * ------------------------------------------------------------------------ * This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited. Wm Lewis

7 6

ARDC response re BGP portal management
by John Gilmore 23 Feb '20

23 Feb '20

Quan Zhou via 44Net <44net(a)mailman.ampr.org> wrote: > Hi all, > Sorry to bother you with a rant, but I'm feeling an urge to ask that what's happening on the AMPR/ARDC. Thank you for your rant. > ## Background > A few weeks ago I have received a harsh email from Chris G1FEF accusing me for announcing a prefix was assigned to me. In that case, the claimed reason is that the prefix wasn't listed on the AMPR portal. > I tried to clear things up by sending him the LOA from WB6CYT, which he claims that is NOT legitimate, also denied possibility there could a bug in the portal caused this. I have also complied with his demands on even more information including all conversations between me and Brian regarding that the assignment. Eventually he continued to ask for even more personal information without justification, threatening that not complying may cause "close of account". > ## Questions > 1. Has all previous assignment by WB6CYT been overruled? Or am I singled out? Previous assignments by Brian (WB6CYT) have not generally been overruled. Brian took very seriously his duty to both make space available to real amateur radio operations and to deny space to opportunists trying to poach the space for commercial, personal, spam/malware or other purposes. Many people requested assignments, and most of them received assignments. Those assignments are and were recorded in the ARDC portal, which was initially programmed by Chris (G1FEF), and operated and evolved by both Brian and Chris. The data in it was supplied by Brian, by net44 users who register to receive allocations, and by the volunteer regional coordinators who make allocations. Any collection of detailed allocations too complicated to fit in one person's memory or on the back of an envelope needs a definitive register that provides the collective memory of all the past decisions. The portal was and remains that definitive register. If your allocation is not in that register, then we'd need to figure out why it isn't. The ARDC Board has access to some of Brian's stored email, as well as backup dumps of the Portal databases, so we can do some searching among those if needed. So far, your rant did not mention the particular IP address allocations involved, so we have had little information to start from. Most allocations are made via country-based and region-based volunteer coordinators, who all have portal accounts with permission to make sub-allocations in their region; Brian did not have to adjudicate most of these. Apparently your allocation is from the China subnet, and apparently Brian was still handling those allocations. My guess is that he did not have a volunteer coordinator for China who both had sufficient experience and that Brian trusted to do the job well. > 2. What are the current rules on allocation now? A snapshot of the latest version of ToS is at: https://web.archive.org/web/20190731094938/https://www.ampr.org/terms-of-se… -- It does not requires personal information beyond ASN addresses. The current rules on allocation have not changed. However, Brian is no longer with us to make decisions based on years of expertise. So anyone who would take over that job will make a number of mistakes as they gain similar expertise. Some of those mistakes will be in allocating addresses to requesters who don't deserve them. Some of the mistakes will be in denying addresses to requesters who do deserve them, or in demanding more scrutiny than is warranted when requests are made. An allocation of 768 IP addresses, such as yours, which has considerable monetary value if used commercially, will naturally get more scrutiny than a typical request for a /29 that only has 8 addresses and can't be routed via BGP. The Chinese agency that licenses amateur radio operators, the State Radio Regulation of China (http://www.srrc.org.cn) does not appear to provide an English-language portal for looking up amateur radio licenses. This currently makes it a more manual process to verify the license status of Chinese hams. See: https://en.wikipedia.org/wiki/Amateur_radio_licensing_in_China (I hope some 44net users from Asia will improve that Wikipedia page, which is still mostly a stub page.) > 3. What is G1FEF's role in the allocation, which are the rights that ARDC holds has been delegated to this guy along. G1FEF has been informally trying to continue providing service to amateurs while the ARDC board and other volunteers scramble to pick up the work that Brian was doing during his lifetime. ARDC and G1FEF have been negotiating a contract that would specify just what rights and powers ARDC would delegate to G1FEF, and which ARDC would retain for exercise by its board (and eventually by a hired staff, which we have been trying to hire the first person of). The first draft contract was full of legalese that one side or the other didn't like, and it also raised some more complex issues such as international privacy practices, so we are re-drafting, consulting lawyers, and continuing to negotiate. > 4. The holding-the-ID-in-a-photo-of-you practice is pretty common when dealing with financial institutions and websites frequently deals with fraudsters. Since LIR, RIR, and BGP upstream also requires and validates these ID, Why this is necessary to do it again? People who get legacy 44.x.y.z IP addresses from 44net don't have to get addresses from an LIR or RIR, so LIR/RIR practices don't provide any safeguard for 44net addresses. Our previous policy, created and enforced by Brian, was not to demand such identity documents of everyone. But Brian did reserve the right to ask more questions and collect more information when he encountered a situation that he thought was questionable, and to use his own judgment in deciding whether to make an allocation. And he sometimes consulted with the board about how to resolve such situations. > 5. Is Chris Smith, G1FEF capable of handling sensitive personal data? He's handling data as natural person, or an legal entity that ARDC approves? At the moment, as a natural person; he's a volunteer. One of the issues being negotiated in the draft contract, and with lawyers, is to what extent ARDC will collect sensitive personal data, how it would safeguard that data that it does collect, and to what extent ARDC will be subject to privacy controls such as the European GDPR. These issues have been handled informally up to the time that Brian died. The current situation is that when Chris requests identification photos or documents, he examines them and then deletes them after approval. > 6. If there's another change, do anyone with a allocation has to go through the same process again? Since we haven't defined any changes yet, we also haven't decided that issue. > I see that we already have a problem with transparency, now we got bureaucracy? Also it's not my problem that the assignment wasn't added to the portal. It is fortunate that small, informal organizations still have room to operate in today's world, and can provide positive benefits to society. ARDC under Brian's leadership was such an organization; the board helped him around the edges, but he was our leader, and he also did most of the work. Now we have no leader experienced in exactly what Brian did. As organizations grow and become more formal, the world expects a degree of impartiality, predictability, and adherence to rules that reduces the flexibility of the informal processes. Quan, you are simultaneously asking that you be given the benefit of an informal process that provided you with the allocation you claim, and yet also asking that we provide predictable rules and adhere to them, rather than continuing informally. There is clearly a tension between these extremes. The ARDC board (all volunteers) and the technical volunteers such as Chris and the regional coordinators are trying to chart a middle course. Thank you for your help in pointing out some of the implications of the choices we are trying to make. It DOES seem to be your problem that the assignment wasn't added to the portal. If your assignment was in the portal, then your allocation would not be getting the scrutiny it is currently getting. As the wiki says in the "Requesting a block" page: https://wiki.ampr.org/wiki/Requesting_a_block "You must request an amprnet block direct from the Portal. First you must create your account at the Portal. Once you do, you must login..." https://wiki.ampr.org/wiki/Announcing_your_allocation_directly "Apply for your AMPRNet allocation via the Portal. Check the Direct box to indicate that your connection will be using a direct announcement of the subnet (via the BGP protocol). "Upon verification and approval, the AMPRNet administrator will provide authorization to your ISP allowing them to announce your allocation." If only one of your three /24 allocations is in the portal, then how did Brian, the very meticulous AMPRNet administrator end up providing you with a Letter of Authorization for the others? > Best Regards, > Quan Best regards back to you, John Gilmore, W0GNU ARDC board member

5 6

Re: [44net] GL.iNet openWRT Rip44 support?
by lleachii＠aol.com 23 Feb '20

23 Feb '20

Tracy N4LGH, I drafted the OpenWrt Wiki with the help of others on the mailing list. The instructions in the Wiki definitely work - I've been running an AMPRNet node on OpenWrt for approximately seven years. I have ampr-ripd compiled for most of my routers. I'm not sure how I missed your previous requests for assistance; but I'm willing to help setup an official OpenWrt firmware installation. 73, - LynwoodKB3VWG

1 0

BGP portal management after WB6CYT's passing
by Phil Karn 22 Feb '20

22 Feb '20

Hi. As you all know, Brian Kantor WB6CYT passed away suddenly last month. Brian did so much for AMPRNet from the very beginning that he'll be impossible to fully replace. We're trying but it's hard, especially since he was a close personal friend. Chris Smith, G1FEF (chris(a)g1fef.co.uk) has kindly volunteered to take over Brian's portal work and to handle portal and BGP allocation requests. Please direct queries to him. 73, Phil Karn, KA9Q President, ARDC

14 22

Manual BGP validation
by Corey Dean 22 Feb '20

22 Feb '20

I switched over to vultr a few weeks ago. To get my BGP announced there, they needed to do the manual verification. After 1 week of no response by the ampr.org team I have had to start with a new ticket and the manual process again. Is there more than one person than can validate the manual BGP verification process? Corey N3FE

2 1

Re: [44net] A few more questions Re: BGP portal management after WB6CYT's passing
by Rob Janssen 21 Feb '20

21 Feb '20

> I know this process can be invasive but you would be surprised how many bogus requests I've received over the years. I have to assume this is because of the scarcity of IPv4 addresses I agree with that! I also get requests from people who just want to use it for internet hosting unrelated to amateur radio, and without mentioning a valid callsign at all. Of course Quan also does not mention his callsign in his mailinglist message. A lookup on QRZ.COM indicates he likely has a BG3 callsign, but for me it would be suspicious when I receive a communication like that because any radio amateur knows that it is customary to use a callsign rather than only first and last name when communicating between radio amateurs. Just last week I got (as the coordinator for Netherlands) a request from someone likely living in Denmark (a nearby country) with just a fake word in the callsign field. Maybe he got turned away by the Danish coordinator and tried with me, maybe he wasn't even aware of the subnetting by country, I don't know. But we really need to watch out for people trying to masquerade as a radio amateur and trying to obtain IP space for free. Of course it doesn't help that the portal does not convey that information. It is likely that googling for services offering IP space somehow refers those people directly to the portal or to a subpage of the wiki, they read some paragraphs about obtaining IP space and never see what is the target audience for this system. That is mentioned only in some toplevel pages, not in the actual procedures for obtaining addresses. Someone from outside our community may not know what "callsign" means and just enter a netname as they would use in whois. So there is room for improvement there. About the ID and personal info requirement, I certainly have not been asked for an ID photo and it would be a problem to have such things on file indeed. But having some personal contact info (like name, callsign, e-mail and street address) should be fine as it is required to contact the registrant in case of problems. Rob PE1CHL

2 1

Re: [44net] Need TraceRoute from UCSD router
by R P 29 Jan '20

29 Jan '20

Thank U i have finally found the problem it was a wrong IP in the tunnel chain it consisted of few routers in series Thank You all for all your help Now additional question : who deal with entering/Changing records in the ampr.org DNS ? I need to update few records in my Network Thanks Forward Ronen - 4Z4ZQ ________________________________ From: John Gilmore <gnu(a)toad.com> Sent: Tuesday, January 28, 2020 12:35 AM To: R P <ronenp(a)hotmail.com>; gnu(a)toad.com <gnu(a)toad.com> Subject: Re: [44net] Need TraceRoute from UCSD router R P via 44Net <44net(a)mailman.ampr.org> wrote: > Steve > May you be kind and make a traceroute from UCSD Router to the Commercial IP of this gateway to see the nodes it passes throug ? I'm not Steve, but here is a traceroute from the UCSD Router to some IP address that was mentioned in the message (you were not specific about what IP address you wanted a trace to, so I just had to guess. Be specific if you are asking people to do some service for you!) John traceroute to 31.44.137.3 (31.44.137.3), 64 hops max, 40 byte packets 1 169.228.34.82 (169.228.34.82) 0.607 ms 0.539 ms 0.606 ms 2 nodem-core-6807-vlan2995-gw.ucsd.edu (132.239.255.49) 0.215 ms 0.245 ms 0.209 ms 3 mx0--nodem-core-30ge.ucsd.edu (132.239.254.162) 0.261 ms 0.227 ms 0.216 ms 4 mx1--mx0-p2p.ucsd.edu (132.239.254.149) 0.566 ms 0.287 ms 0.265 ms 5 riv-agg4--ucsd-2.cenic.net (137.164.23.57) 3.240 ms 3.206 ms 3.152 ms 6 dc-lax-agg6--riv-agg8-100ge-2.cenic.net (137.164.22.46) 5.016 ms dc-lax-agg6--riv-agg8-100ge.cenic.net (137.164.11.2) 5.173 ms 5.120 ms 7 8-1-1-90.ear1.LosAngeles1.Level3.net (4.35.156.65) 4.925 ms 4.916 ms 4.920 ms 8 ae-1-3111.edge4.London1.Level3.net (4.69.141.230) 135.741 ms 135.784 ms 135.748 ms 9 195.122.180.186 (195.122.180.186) 209.543 ms 209.932 ms 209.580 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * *

3 3

Re: [44net] PKTerrors.
by lleachii＠aol.com 28 Jan '20

28 Jan '20

Bill, I attempted to look through my records for 138.88.77.89 on my interface and I see quite a bit of packets from you - so much so that it crashed my NetFlow console upon searching your IP with a setting of 10,000 flows. I am receiving encapsulated packets from you, and it seems you've pointed traffic towards me. Firewall: 203.87 K 11.09 MB zone_amprwan_dest_DROP all * * 0.0.0.0/0 0.0.0.0/0 - AMPR_DropLoop Encapsulated: Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows 2020-01-26 10:01:01.733 202.005 IPIP 138.88.77.89:0 -> 141.75.245.225:0 28 8758 1 2020-01-26 10:01:01.733 202.005 IPIP 141.75.245.225:0 -> 138.88.77.89:0 28 2371 1 2020-01-26 10:18:02.902 419.571 IPIP 138.88.77.89:0 -> 90.155.50.1:0 116 9976 1 2020-01-26 10:26:40.783 13495.994 IPIP 176.121.81.53:0 -> 138.88.77.89:0 107 8922 1 de-encapsulated: Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows 2020-01-26 09:18:45.097 88198.195 TCP 138.88.77.89:41958 -> 3.219.211.244:8883 7209 879799 1 2020-01-26 09:18:45.097 88198.195 TCP 3.219.211.244:8883 -> 138.88.77.89:41958 5618 341324 1 2020-01-26 09:31:05.692 86085.778 TCP 138.88.77.89:38410 -> 69.147.82.61:443 8792 2.7 M 1 2020-01-26 09:31:05.692 86085.778 TCP 69.147.82.61:443 -> 138.88.77.89:38410 7968 1.6 M 1 - KB3VWG

5 4

Need TraceRoute from UCSD router
by R P 28 Jan '20

28 Jan '20

Hi there Im trying to debug why one of our hams dont have tunnel up an running (or actually why one day it stopped working for him ) I suspect there are a routing problem from UCSD side to his ISP I wrote Brian mail asking to login to the UCSD HAM router and make a trace route to this local ham so i can track the problem Who can help me now ? is there anyone that have the ability to login and make trace route maybe Chris ? or any other solution ? The MikroTik Router he have declare that no route to UCSD and the tunnel status is down but from the router side ping can be done to UCSD ham router Is there any chance to do a web interface on UCSD Router that will give the option to the users to make trace route from there to a certain destination using the 44 and the non 44 interface ? something like this https://ping.eu/traceroute/ Thans forware for any assistance Ronen - 4Z4ZQ

6 9

Re: [44net] PKTerrors.
by lleachii＠aol.com 27 Jan '20

27 Jan '20

Bill, The crash truncated the IPs in the search; showing my IP. Forcing a dynamic IP change on WAN helped me realize my error. But now, I get ICMP unreachable messages in reply to my pings. root@OpenWrt:~# tcpdump -vv -i eth0.2 host 90.155.50.1 -ntcpdump: listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes16:46:24.510501 IP (tos 0x0, ttl 64, id 36329, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64173, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 0, length 6416:46:24.626840 IP (tos 0xc0, ttl 54, id 44297, offset 0, flags [none], proto ICMP (1), length 132) 90.155.50.1 > 138.88.77.109: ICMP 90.155.50.1 protocol 4 port 84 unreachable, length 112 IP (tos 0x0, ttl 56, id 36329, offset 0, flags [none], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64173, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 0, length 6416:46:25.510864 IP (tos 0x0, ttl 64, id 37129, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64530, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 1, length 6416:46:25.614088 IP (tos 0xc0, ttl 54, id 44337, offset 0, flags [none], proto ICMP (1), length 132) 90.155.50.1 > 138.88.77.109: ICMP 90.155.50.1 protocol 4 port 84 unreachable, length 112 IP (tos 0x0, ttl 56, id 37129, offset 0, flags [none], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64530, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 1, length 6416:46:26.511170 IP (tos 0x0, ttl 64, id 37676, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64733, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 2, length 6416:46:26.637354 IP (tos 0xc0, ttl 54, id 44392, offset 0, flags [none], proto ICMP (1), length 132) 90.155.50.1 > 138.88.77.109: ICMP 90.155.50.1 protocol 4 port 84 unreachable, length 112 IP (tos 0x0, ttl 56, id 37676, offset 0, flags [none], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64733, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 2, length 6416:46:27.511520 IP (tos 0x0, ttl 64, id 38445, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64775, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 3, length 6416:46:27.617907 IP (tos 0xc0, ttl 54, id 44428, offset 0, flags [none], proto ICMP (1), length 132) 90.155.50.1 > 138.88.77.109: ICMP 90.155.50.1 protocol 4 port 84 unreachable, length 112 IP (tos 0x0, ttl 56, id 38445, offset 0, flags [none], proto IPIP (4), length 104) 138.88.77.109 > 90.155.50.1: IP (tos 0x0, ttl 64, id 64775, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 8551, seq 3, length 64^C8 packets captured8 packets received by filter0 packets dropped by kernel - KB3VWG

1 1

PKTerrors.
by W.B.Hill 27 Jan '20

27 Jan '20

Hi, Just been looking through https://gw.ampr.org/private/pkterrors.txt and I noticed there's entries for the external IP for the net I run. I'm running 44.131.170.0/30 with a RaspberryPi on 44.131.170.1 using IPIP with amprd, external IP address 90.155.50.1 The errors are like: 90.155.50.1 51.89.173.198 2 [19] dropped: non-44 inner source address What does this mean? And I can't seem to ping to 44.131.170.1 from the big bad internet, is this related? Thanks. Bill (M1BKF)

4 8

Re: [44net] PKTerrors.
by lleachii＠aol.com 27 Jan '20

27 Jan '20

All, I'm able to ping all three of Steve's IPs from 44.60.44.0/24. - LynwoodKB3VWG

1 0

Re: [44net] PKTerrors.
by lleachii＠aol.com 27 Jan '20

27 Jan '20

Bill, Can you reach me now as well? root@OpenWrt:~# ping 44.131.170.1 -I 44.60.44.1PING 44.131.170.1 (44.131.170.1) from 44.60.44.1: 56 data bytes^C--- 44.131.170.1 ping statistics ---4 packets transmitted, 0 packets received, 100% packet loss I still receive no IPIP packets on my WAN from 90.155.50.1. I also ran "tcpdump -vv -i eth0.2 -n proto 4" - I see no replies from any IP. 44.60.44.144.60.44.254 73, - Lynwood KB3VWG

1 0

Re: [44net] PKTerrors.
by lleachii＠aol.com 26 Jan '20

26 Jan '20

Bill, That error means that you are encapsulating an IP that does not equal a 44 IP (e.g. you're improperly sending multicast, broadcast or your Public IP onto the tunnel). Ensure that you only send 44-net SRC IPs inside the tunnel. Also, any 44 IP that you want to reach the Internet must have a DNS entry in the AMPR.ORG and 44 reverse zones. That seems to be properly setup already: 1.170.131.44.in-addr.arpa name = m1bkf.ampr.org. --- I ping and receive no reply - this is a TCPDUMP of my tunnel: 21:23:10.793135 IP (tos 0x0, ttl 64, id 46020, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.89 > 90.155.50.1: IP (tos 0x0, ttl 64, id 48759, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 19216, seq 7, length 64 21:23:11.793459 IP (tos 0x0, ttl 64, id 46092, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.89 > 90.155.50.1: IP (tos 0x0, ttl 64, id 48962, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 19216, seq 8, length 64 21:23:12.793801 IP (tos 0x0, ttl 64, id 46294, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.89 > 90.155.50.1: IP (tos 0x0, ttl 64, id 49447, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 19216, seq 9, length 64 21:23:13.794158 IP (tos 0x0, ttl 64, id 46674, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.89 > 90.155.50.1: IP (tos 0x0, ttl 64, id 49657, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 19216, seq 10, length 64 21:23:14.794465 IP (tos 0x0, ttl 64, id 47472, offset 0, flags [DF], proto IPIP (4), length 104) 138.88.77.89 > 90.155.50.1: IP (tos 0x0, ttl 64, id 50140, offset 0, flags [DF], proto ICMP (1), length 84) 44.60.44.1 > 44.131.170.1: ICMP echo request, id 19216, seq 11, length 64 73, - Lynwood KB3VWG

4 9

Link(s)
by gm4upx＠gb7jd.co.uk 25 Jan '20

25 Jan '20

Hello Matt, You may by now have found a solution to your problem; I had a similar problem when setting up a remote node last week via a mobile phone sim card ( cell net phone ! ). I found I could not connect from the remote node until I removed the default entry in iptables and used ip rules to get a two way connection. Regards, Ian.. A totally in-experienced user <smile>

1 0

Help troubleshooting AXIP link
by VE3OY Matt 24 Jan '20

24 Jan '20

Hello 44Net. I'm looking for some help from those who have experience! I have recently set up my first AXIP link through the 44Net, but I'm having trouble connecting to my AXIP partner. My IP is 44.135.88.200 and my partner is 44.135.32.201 So far I can TELNET and PING back and forth from ANY 44 node, yet all attempts to make a AX25 connection to my AXIP partner fail. I can TELNET/PING from my partner to my node okay. I can TELNET/PING to my partner from my node okay. I can PING the 44 gateway without issue. I have also been broadcasting my NODES table to my partner. My partner does not seem to "hear" my CONN REQ's or NODES broadcasts. My partner is also broadcasting his NODES table to me. I am not hearing his broadcasts. Using TCPDUMP and WIRESHARK, I can see the traffic going out my tunnel to my regional gateway. I have tried to capture AX25 packets FROM my partner ... nothing heard. I have been able to capture AX25 packets TO my partner ... all looks correct. I have been able to capture packets when TELNETing or PINGing. TRACEROUTEs to my partner work fine (2 hops). My situation is a little more complex because I am not going direct to the UCSD gateway. Instead, I am sending all my 44Net traffic through my regional gateway (44.135.88.252). It has been suggested that my ISP may be "source filtering", but i have no way of verifying that. I am running both my router and node on a Raspberry Pi (I know ... plug your nose! LOL) I am using IPTABLES, which I have disabled for testing to see if it was interfering (it wasn't). My router/node is behind a CPE router, and is in the DMZ. I have several AX-UDP ports working fine. So here are my questions: Does it sound like I am suffering from source filtering? How can I verify whether my ISP is source filtering? What have I overlooked in my troubleshooting? What would you suggest as my next step? Any and all suggestions are welcome. I'm going bald quickly pulling out my hair! Thanks in advance, Matt VE3OY (FN03gq) Toronto, Canada -- /My mind is like a web browser. 27 tabs are open, 9 aren't responding, lots of pop-ups...and where is that annoying music coming from?/

1 0

Re: [44net] 44 compatible Routers
by lleachii＠aol.com 24 Jan '20

24 Jan '20

Angelo, You can search the archive; but everyone's been fairly diligent in adding configuration information for supported devices/NOSes and linking on the main Wiki page: http://wiki.ampr.org/wiki/Main_Page 73, - Lynwood KB3VWG

1 0

Re: [44net] Need TraceRoute from UCSD router
by lleachii＠aol.com 24 Jan '20

24 Jan '20

Charles and Quan, Please read Friday's email digest, the password was provided. Also, since you have an account in the portal...doesn't that mean you have a gateway? - Lynwood KB3VWG

1 0

Vultr BGP routing KO in Paris ?
by Toussaint OTTAVI 24 Jan '20

24 Jan '20

Hi all, Our subnet 44.190.11.0/24 does not seem to be reachable anymore from Internet. It's announced in BGP via a Vultr VPS located in Paris. I had notices from Vultr in the last few days about network upgrades. Currently, the route to our gateway 44.190.11.1 seems to be the default route via UCSD. I opened a support ticket. I know some of us are using Vultr. Do you encounter similar problems ? Thank you in advance, 73 de TK1BI

5 10

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net