Very good info. I will definitely keep that one in mind as I continue this venture. Thanks Marius Harold K7ILO From: Marius Petrescu <marius(a)yo2loj.ro> Date: Tuesday, September 27, 2022 at 2:21 PM To: k7ilo(a)outlook.com <k7ilo(a)outlook.com>om>, 44net(a)mailman.ampr.org <44net(a)mailman.ampr.org> Subject: Re: [44net] ftp access to encap.txt Harold, Since the RIPv2 packets are sent IPIP encapsulated from amprgw to your registered gateway, it has nothing to do with your ISP blocking that port. If your IPIP tunnels are working, so will the RIP delivery. On the other hand, if your ISP blocks IPIP (IP protocol 4), none of the tunnels will work and all efforts are futile. Marius, YO2LOJ On 28/09/2022 00:02, Harold via 44net wrote:

Here is what I email out to my new AMPR users in the Silicon Valley region to help users do initial testing to confirm things will work or not. Give these testing steps a try and see if it works for you. --David -- Hello first name / callsign, Welcome to AMPR! I have assigned you: Subnet - 44.4.x.y/z 44.4.x.x : network 44.4.x.y-94 : host IPs 44.4.x.z : broadcast You should receive an email shortly of this official acceptance from the AMPR Portal itself. At this point, there are a few more things you to do before things will start working: 1. If you are going to use IPIP tunneling, You need to log into the AMPR portal and configure a gateway IP address. This IP address is your EXTERNALLY facing IPv4 address given to you by your ISP that will be used to route your AMPR IP or AMPR subnet via IPIP encapsulation. This will ideally be a static IP address from your service provider. IPIP (protocol 4) over IPv4 is the only supported encapsulation today and supported protocol today from the native AMPR system. If your ISP does not pass protocol-4 traffic or your ISP-provided hardware blocks this traffic (aka Comcast cablemodems, some consumer Wifi "routers", etc), you can configure your AMPR traffic to be received via other transports provided by other helpful HAMs. Some of these alternative transports include IPSEC, GRE, and PPTP. 2. If you wish to have your AMPR IPs or subnets able to receive periodic dynamic route updates to other AMPR IPIP-enabled station subnets (RIP routing) *or* directly receive traffic from the Internet to your AMPR IPs, additional action is required. Dynamic routing is an alternative to using static routes via the the encap_[date].txt file or loading the nexthop IP addresses yourself. You *must* create DNS records for the AMPR IPs that have been allocated to you to receive both the RIP updates as well as allow any traffic from Internet to reach your AMPR IPs. To get DNS entries created, reply to this email with a list of your AMPR IPs and your desired hostnames and/or other DNS records and I will configure them on your behalf. You CANNOT create / update / delete DNS entries yourself at this time due to AMPR portal limitations. For example, here is what you could email me for DNS entries though valid IPv4 or IPv6 records (A, AAAA, CNAME, MX, DKIM, TXT HINFO, etc). Here is an example of setting "bbs-n0call" and "backup-bbs-n0call" for the 44.4.10.280 and 44.4.10.281 IP addresses: Record MX IP type weight hostname ------------:-------:------:----------------------- 44.4.10.280 : A : : bbs-n0call.ampr.org 44.4.10.280 : MX : 10 : bbs-n0call.ampr.org gw-n0call : CNAME : : bbs-n0call.ampr.org 44.4.10.281 : A : : backup-bbs-n0call.ampr.org Please note: ------------ As mentioned above, DNS changes *CANNOT* be made by endusers via the AMPR portal or any other AMPR mechanism today. Only AMPR coordinators can do this at the moment. Please email me at amprgw(a)trinnet.net with what you want in your DNS records (example is above) and I'll configure that shortly. 3. If you're looking for some working AMPR IP addresses to ping or use other AMPR troubleshooting tools to help you get / confirm things are working, see the AMPR Services wiki (available via the Internet as well) at http://wiki.ampr.org/wiki/Services 4. IPIP tunneling: Many AMPR systems are only available via the IPIP tunneling mesh which is available to many systems including: - Any Linux, FreeBSD based systems - NOSes like JNOS, BPQ32, etc. - Routers like Mikrotik, Cisco, Juniper, etc See https://wiki.ampr.org/wiki/Main_Page for other device examples 5. Example IPIP compatibility testing with a Linux computer: Consider you want to see if your ISP does or doesn't block protocol 4 / IPIP traffic. a. REQUIRED: Update the AMPR portal with the correct Internet IP address that will be terminating your IPIP tunnel. b. RECOMMENDED: Send me (your AMPR coordinator) a hostname for at least one AMPR IP address you will want to receive traffic. I will enter these names into the reserve DNS interface. c. Wait roughly 60 minutes until the IPIP mesh gets new routes for your information to propagate through the AMPR mesh network d. On your intended system that will be the AMPR IPIP endpoint, run the command: #Assuming eth0 is your uplink port tcpdump -nni eth0 proto 4 e. While tcpdump is running in one window on your Linux machine, open up a web browser using your standard Internet connection to: http://yo2tm.ampr.org/nettools.php Enter in the desired AMPR IP host address (not subnet address) you're using to terminate your IPIP connection and click on "IPv4 ping". If your ISP is properly forwarding you IPIP traffic, your AMPR gateway should see something like the following on the tcpdump window: -- 13:12:15.876817 IP 89.122.215.236 > 96.78.144.186: IP 44.182.21.1 > 44.4.10.40: ICMP echo request, id 37699, seq 1, length 64 (ipip-proto-4) 13:12:15.877272 IP 96.78.144.186 > 89.122.215.236: IP 44.4.10.40 > 44.182.21.1: ICMP echo reply, id 37699, seq 1, length 64 (ipip-proto-4) 13:12:16.876362 IP 89.122.215.236 > 96.78.144.186: IP 44.182.21.1 > 44.4.10.40: ICMP echo request, id 37699, seq 2, length 64 (ipip-proto-4) 13:12:16.876788 IP 96.78.144.186 > 89.122.215.236: IP 44.4.10.40 > 44.182.21.1: ICMP echo reply, id 37699, seq 2, length 64 (ipip-proto-4) 13:12:17.876889 IP 89.122.215.236 > 96.78.144.186: IP 44.182.21.1 > 44.4.10.40: ICMP echo request, id 37699, seq 3, length 64 (ipip-proto-4) -- ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^ yo2tm's public your public yo2tm's your Internet addr Internet addr AMPR addr AMPR addr If you don't see traffic like that, you either probably didn't set your Internet gateway IP address on the AMPR portal correctly. Alternatively, your ISP is blocking IPIP traffic which isn't all that uncommon. There are ways around this with VPNs and what not so see the AMPR Wiki (details below). 4. If your AMPR IPs will be interacting with systems on the Internet, consider reaching out to GeoIP vendors like Maxmind and other vendors to get your new AMPR subnet properly located to your specific geographical region. Many systems on the Internet use GeoIP lookups to point you to the nearest systems for the best performance, lowest latency, etc. 5. It's recommended to join the AMPR email alias get updates on the network, any upcoming changes, maintenance windows, as well as be the best place to ask questions, etc. This is a low volume email list: https://mailman.ampr.org/mailman/listinfo/44net 6. Once a year, you will receive an email requesting you to log into the AMPR portal just to confirm you want to keep your AMPR allocation. If you do not so, your allocation will eventually be released and put back into the available AMPR IP allocation pool. Good luck and again, welcome to the AMPR system! --David KI6ZHD Silicon Valley, CA AMPR Coordinator -- On 09/27/2022 04:01 PM, Harold Kinchelow via 44net wrote:

I do not think that a DNS entry for the gateway is needed to receive the RIP updates. If you register your gateway and assign a subnet to it, you get the data via the IPIP tunnel from amprgw. At least it was that way at some point. Maybe Chris could clarify this. To my understanding, the only moment you need those DNS entries is if your hosts need to pass traffic through amprgw to the internet and back, and only affects the routing/firewall part at amprgw. An "official" statement on this topic would be useful. Marius, YO2LOJ On 28/09/2022 02:15, David Ranch via 44net wrote:

Hey Chris, Marius, Ok, thank you for the correction though I clearly remember that "something" additional was required before RIP updates would start flowing over the IPIP tunnel other than the user just defining their gateway IP address for the IPIP tunnel endpoint. What is "that". --David KI6ZHD On 09/27/2022 11:27 PM, Chris Smith via 44net wrote:

Just flash your router with dd-wrt if it can't pass ipip and the problem is solved. Bob On 2022-09-28 14:33, Rob PE1CHL via 44net wrote: -- There is nothing permanent except change -Heraclitus

Yes, it will work if dd-wrt is available for the chip-set in it, so you have to flash it with the right version. It is the first thing I  do if I receive such a modem, re-flash it with dd-wrt if that is not in it. There is a good change that nowadays dd-wrt is already in it with new modems.  At least, that is what I see here. Bob On 2022-09-28 16:08, Lee D Bengston wrote: -- There is nothing permanent except change -Heraclitus

You should always re-flash the modems your own, I assumed that. Don't touch their stuff. It is essential that you know the network settings of the network you are on, things like the VPI/VCI  (DSL) for the region you are in, connection type, etc., so that you can configure dd-wrt afterwards correctly.  You don't always see the VPI/VCI  in the old proprietary firmware as it maybe hidden (as far as I remember), but you need it anyhow and it has to be the right value. You can look it up at Internet or you can get it from your provider.  There is no reason why a provider would refuse a modem with dd-wrt in it and I never experienced it with several providers in the Toronto area, but you need the right network parameters. Bob.   On 2022-09-28 16:48, Roger wrote: -- There is nothing permanent except change -Heraclitus

If you go the bridge mode option then look at putting VyOS behind it. It's a great open source router, full featured, and as fast as the hardware you put it on. It runs on regular x86 hardware. I've used it for years. It's a fork of Vyatta before it went private. VyOS.io Thank you, Barry Bahrami KN6MVB On Fri, Sep 30, 2022 at 6:26 AM KI5PGJ via 44net <44net(a)mailman.ampr.org> wrote:

Ok gang!!! It seems I am working now. Soooooooo lets start from the beginning. I believe the modem/router combo provided by my ISP was the problem all along so I bought a nice TP-Link AX5400 and put the ISP’s modem into bridge mode. The WIFI was starting to fail so buying a new router or replacing theirs was on the TO-DO list anyway. Now the router gets the public ip. I also created a domain name with no-ip for my dynamic ip address issue because I knew I would be switching devices on the modem and the public Ip would be changing. When I have an IP, it doesn’t really change but I did it anyway and updated my gateway info on the portal. The router has a built-in updating client and works pretty quick. Next I put my proposed ampr gateway machine on a dmz port of this new router and at that point made some iptables entries which I’m not sure they were necessary for this next step but did it anyway because I may need it for the step after this one. iptables -A INPUT -p 4 -j ACCEPT iptables -A INPUT -p udp --dport 520 -j ACCEPT and for S & G’s, enabled NAT with…. iptables -t nat -A PREROUTING -p 4 -j DNAT –to 10.10.0.2 <=ip address of my network card on machine I also made sure I had enabled net.ipv4.ip_forward=1 I then started tcpdump with tcpdump -I eth0 -vvv host amprgw.ucsd.edu and WOO HOO!! I started seeing RIP announcements within a minute or so. At the 15 minute or so mark of this, I figured if I saw this, then ampr-ripd should work so I…… Started @ 2054 UTC ampr-ripd with /usr/sbin/ampr-ripd -d -v -I tunl0 and @ 2055 I started seeing RIP announcements soooooooo Again, it seems it was the router capabilities of this modem/router combo from my ISP that was the issue. This means I can move forward with the next steps of setting up this gateway. Thanks everyone for chiming in with their ideas and the added conversations in this thread. They all helped me figure this mess out. 73 everyone Harold K7ILO From: Tim Požar via 44net &lt;44net(a)mailman.ampr.org&gt; Date: Friday, September 30, 2022 at 8:00 AM To: Barry Bahrami &lt;barrybahrami(a)gmail.com&gt;om>, KI5PGJ &lt;ki5pgj(a)placebonol.com&gt; Cc: AMPRNet working group &lt;44net(a)mailman.ampr.org&gt; Subject: [44net] Re: ftp access to encap.txt +1 on Vyos. I have it running on a VM as a VPN server and router. If you are used to EdgeOS, you will be comfortable with Vyos as EdgeOS forked from it some years ago. Very Junos-like. Tim On 9/30/22 7:18 AM, Barry Bahrami via 44net wrote: _______________________________________________ 44net mailing list -- 44net(a)mailman.ampr.org To unsubscribe send an email to 44net-leave(a)mailman.ampr.org

You hit the nail on the nail head, PROPER DMZ. Didn’t work on the previous equipment. What also gave it away were other issues I started noticing with the modem/router. I have an ALLSTARLINK repeater on my network which uses UDP port 4569. I noticed that my port forwards for all of my services were deleted, including ALLSTAR but it still made connections to other nodes so that told me that there were issues deeper than what I could see in the GUI. Anyway, we’re good. I am notating my build with Debian 11 because there are some things with it that are different from earlier versions or even Ubuntu which is documented on the WIKI. Not many. Ill provide em if wanted/needed. Thanks again everyone. I’m sure I’ll have some other questions as I complete this setup. Harold K7ILO From: Steve L &lt;kb9mwr(a)gmail.com&gt; Date: Sunday, October 2, 2022 at 9:18 PM To: Harold Kinchelow &lt;k7ilo(a)outlook.com&gt; Cc: AMPRNet working group &lt;44net(a)mailman.ampr.org&gt; Subject: Re: [44net] Re: ftp access to encap.txt Harold's message here is likely something that should be incorporated into the Wiki. Recapping 1.) Whenever possible the customer premise equipment CPE should be something you own if you have that option. Provider combo modem/router units often lack features that we'd need, like proper DMZ implementations. As some have noted, sometimes they only forward TCP UDP. And other times we have seen protocol 4 being treated statefully. 2.) Barring those options, if the availability to place the equipment into a bridge mode or DMZ mode then point that to your ampr gateway system. 3.) Then run "tcpdump -I eth0 -vvv host amprgw.ucsd.edu" to verify you are receiving the protocol 4 based RIP announcements 4.) If successful then apply firewall rules to your gateway, etc. Glad you got it working Steve On Sun, Oct 2, 2022 at 4:02 PM Harold Kinchelow via 44net &lt;44net(a)mailman.ampr.org&gt; wrote:

Will do Chris Thanks Harold K7ILO From: Chris Smith &lt;chris(a)ardc.net&gt; Date: Monday, October 3, 2022 at 12:17 AM To: Harold Kinchelow &lt;k7ilo(a)outlook.com&gt; Cc: Steve L &lt;kb9mwr(a)gmail.com&gt;om>, AMPRNet working group &lt;44net(a)mailman.ampr.org&gt; Subject: Re: [44net] ftp access to encap.txt Harold, Please do write up your experiences and add them to the Wiki, that’s what it’s for and it only works if folk contribute! Thanks, Chris - G1FEF On 3 Oct 2022, at 05:30, Harold Kinchelow via 44net <44net@mailman.ampr.org<mailto:44net@mailman.ampr.org>> wrote: You hit the nail on the nail head, PROPER DMZ. Didn’t work on the previous equipment. What also gave it away were other issues I started noticing with the modem/router. I have an ALLSTARLINK repeater on my network which uses UDP port 4569. I noticed that my port forwards for all of my services were deleted, including ALLSTAR but it still made connections to other nodes so that told me that there were issues deeper than what I could see in the GUI. Anyway, we’re good. I am notating my build with Debian 11 because there are some things with it that are different from earlier versions or even Ubuntu which is documented on the WIKI. Not many. Ill provide em if wanted/needed. Thanks again everyone. I’m sure I’ll have some other questions as I complete this setup. Harold K7ILO From: Steve L <kb9mwr@gmail.com<mailto:kb9mwr@gmail.com>> Date: Sunday, October 2, 2022 at 9:18 PM To: Harold Kinchelow <k7ilo@outlook.com<mailto:k7ilo@outlook.com>> Cc: AMPRNet working group <44net@mailman.ampr.org<mailto:44net@mailman.ampr.org>> Subject: Re: [44net] Re: ftp access to encap.txt Harold's message here is likely something that should be incorporated into the Wiki. Recapping 1.) Whenever possible the customer premise equipment CPE should be something you own if you have that option. Provider combo modem/router units often lack features that we'd need, like proper DMZ implementations. As some have noted, sometimes they only forward TCP UDP. And other times we have seen protocol 4 being treated statefully. 2.) Barring those options, if the availability to place the equipment into a bridge mode or DMZ mode then point that to your ampr gateway system. 3.) Then run "tcpdump -I eth0 -vvv host amprgw.ucsd.edu<http://amprgw.ucsd.edu>" to verify you are receiving the protocol 4 based RIP announcements 4.) If successful then apply firewall rules to your gateway, etc. Glad you got it working Steve On Sun, Oct 2, 2022 at 4:02 PM Harold Kinchelow via 44net <44net@mailman.ampr.org<mailto:44net@mailman.ampr.org>> wrote: _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org<mailto:44net@mailman.ampr.org> To unsubscribe send an email to 44net-leave@mailman.ampr.org<mailto:44net-leave@mailman.ampr.org>